Projet Ledger Live Monorepo : Partie 2 – Les outils (le faire briller) | registre

Deuxième article de la série d'articles de blog « Ledger Live Monorepo Project », où un développeur Ledger nous raconte l'histoire de l'énorme migration de la base de code Ledger Live vers un référentiel mono. Si vous avez manqué la première partie, regardez-la ici :

Après avoir établi qu’une architecture monorepo était une solution viable, nous avons alors commencé à examiner les outils disponibles pour mettre en place notre plan.

Gestion de plusieurs projets

Dans l'équipe Ledger Live, nous naviguons dans l'écosystème JavaScript, et heureusement pour nous, nous connaissions déjà plusieurs façons de gérer plusieurs projets avec notre gestionnaire de packages. Certaines de ces solutions possibles incluent :

• NPM (prend en charge les espaces de travail mais de meilleures alternatives),
• Fil 1 (devenir trop vieux, alternatives meilleures et plus efficaces),
• Fil ≥ 2 (idée intéressante, mais plug n play pas bien supporté partout, surtout avec React Native),
• PNPM (liens symboliques, construits en pensant aux espaces de travail, efficaces sur le disque).

Après avoir examiné tout cela, nous avons décidé d'opter pour PNPM pour:

• l'efficacité du disque (il utilise un virtuel Boutique ainsi que liens symboliques, les packages ne sont donc téléchargés qu'une seule fois puis liés symboliquement à vos node_modules depuis le magasin virtuel),
• la vitesse (puisque les packages sont mis en cache, les installations ultérieures sont beaucoup plus rapides),
• Prise en charge intégrée des espaces de travail/architecture monorepo (alias, orchestration, etc.).

Sur le papier PNPM est un joyau absolu, mais les liens symboliques étaient un peu étranges à configurer correctement (encore une fois, spécialement avec React Native).

Ok, donc notre choix était fait, nous partirions avec PNPM.

Orchestration des scripts

Même si PNPM ajoute de plus en plus d'orchestration à ses fonctionnalités, il ne couvre toujours pas tout ce que nous voulions faire, comme :

• constructions séquentielles,
• mise en cache.

Pour ceux-ci, nous avons trouvé deux concurrents intéressants que nous devions examiner :

• NX (par l'équipe angulaire),
• Turbodépôt (qui vient d'annoncer la v1.0.0 lorsque nous avons commencé à travailler dessus, et que nous travaillons maintenant avec l'équipe Vercel).

Nous avons fait une preuve de concept sur les deux.

NX avait beaucoup plus de fonctionnalités, de générateurs, d'automatisation, d'excellents graphiques de dépendances, etc… mais cela ajoutait beaucoup de frais généraux, et comme c'est assez opiniâtre, nous devions suivre leurs conventions.

Turbodépôt d'un autre côté, c'est assez basique en termes de fonctionnalités. Il s’agit pourtant d’une solution plug and play pratique que nous pourrions modifier très rapidement si jamais le besoin s’en fait sentir.

Même si Turbodépôt avait moins de fonctionnalités que NX, il a fait les 2 choses que nous recherchions :

• Orchestration des builds respectant l'arborescence des dépendances (et des builds concurrents),
• Mise en cache (les builds sont mis en cache et « rejoués » si leur code n'a pas changé).

Cela, plus la facilité d'inscription et d'abandon, nous a incités à choisir le petit nouveau du quartier, TurboRepo.

Versioning

Nous avons également étudié plusieurs solutions, mais avons finalement décidé d'utiliser https://github.com/changesets/changesets car c'était un outil recommandé par TurboRepo, et après un peu de lecture de la documentation, il semblait répondre à nos besoins.

Les développeurs devraient être un peu plus rigoureux dans leur flux de développement et fournir changesets (fichier décrivant quelle bibliothèque leur code change, la gravité suite à la couper convention et une description du changement). Ces changesets sont ensuite utilisés pour augmenter automatiquement la version des packages respectant les sévérités données, ainsi que pour automatiser la génération des changelogs. En plus de cela, les outils permettent pre release mode, le 🍒 sur le 🍰.

Et après ?

Après avoir choisi les outils, il était temps de commencer à travailler. Dans le prochain article du blog, nous parlerons du système de build et de tous les dev-ops/automatisation/intégration continue dans le contexte d'un référentiel mono.

---

Valentin DE ALMEIDA
Expérience de développeur et technologie de base – Ledger Live

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
• La source: https://www.ledger.com/blog/ledger-live-monorepo-project-part-2-the-tools-make-it-shine