Ledger Live Monorepo-project: deel 2 - De tools (Make it Shine) | Grootboek

Ledger Live Monorepo-project: deel 2 – De tools (Make it Shine) | Grootboek

Bronknooppunt: 2985172

Tweede artikel in de serie blogposts “Ledger Live Monorepo Project”, waarin een Ledger-ontwikkelaar ons het verhaal vertelt van de enorme migratie van de Ledger Live-codebase naar een monorepository. Mocht je deel 1 gemist hebben, bekijk hem dan hier:

Nadat we hadden vastgesteld dat een monorepo-architectuur een haalbare oplossing was, begonnen we te kijken naar de beschikbare tools om ons plan uit te voeren.

Het afhandelen van meerdere projecten

In het Ledger Live-team navigeren we in het JavaScript-ecosysteem, en gelukkig voor ons wisten we al verschillende manieren om meerdere projecten af ​​te handelen met onze pakketbeheerder. Enkele van deze mogelijke oplossingen zijn onder meer:

  • NPM (heeft ondersteuning voor werkruimtes maar betere alternatieven),
  • Garen 1 (te oude, betere en efficiëntere alternatieven worden),
  • Garen ≥ 2 (interessant idee, maar plug-and-play wordt niet overal goed ondersteund, vooral niet met React Native),
  • PNPM (symlinks, gebouwd met werkruimten in gedachten, schijfefficiënt).

Nadat we dit allemaal hadden bekeken, besloten we om mee te gaan PNPM voor:

  • de schijfefficiëntie (het gebruikt een virtueel shop en symlinks, dus pakketten worden slechts één keer gedownload en vervolgens symbolisch gekoppeld aan uw node_modules vanuit de virtuele winkel),
  • de snelheid (aangezien pakketten in de cache worden opgeslagen, zijn daaropvolgende installaties veel sneller),
  • ingebouwde ondersteuning voor werkruimten/monorepo-architectuur (aliassen, orkestratie enz...).

Op papier PNPM is een absoluut juweeltje, maar symlinks waren een beetje vreemd om correct in te stellen (nogmaals, vooral met React Native).

Oké, dus onze keuze was gemaakt, we zouden mee gaan PNPM.

Scriptorkestratie

Hoewel PNPM voegt steeds meer orkestratie toe aan de functies, maar dekt nog steeds niet alles wat we wilden doen, zoals:

  • opeenvolgende builds,
  • cachen.

Hiervoor hebben we twee interessante kanshebbers gevonden waar we naar moesten kijken:

  • NX (door het hoekige team),
  • turborepo (die zojuist v1.0.0 heeft aangekondigd toen we eraan begonnen te werken, en nu samenwerken met het Vercel-team).

Voor beide hebben we een proof of concept gedaan.

NX had veel meer functies, generatoren, automatisering, geweldige afhankelijkheidsgrafieken enz. maar het voegde veel overhead toe, en omdat het behoorlijk eigenwijs is, zouden we hun conventies moeten volgen.

turborepo aan de andere kant is het qua functionaliteit vrij basaal. Toch is het een handige plug-and-play-oplossing die we heel snel kunnen veranderen als dat ooit nodig is.

Hoewel turborepo had minder kenmerken dan NX, het deed de 2 dingen waar we naar op zoek waren:

  • Orkestratie van builds met inachtneming van de afhankelijkheidsboom (en gelijktijdige builds),
  • Caching (builds worden in de cache opgeslagen en 'opnieuw afgespeeld' als de code niet is gewijzigd).

Dat, plus de gemakkelijke in- en uitstap, zorgde ervoor dat we voor de nieuweling in de buurt kozen, TurboRepo.

Versioning

We hebben ook verschillende oplossingen bekeken, maar uiteindelijk besloten om deze te gebruiken https://github.com/changesets/changesets omdat het een hulpmiddel was dat TurboRepo aanbeveelde, en na wat documentatielezen leek het aan onze behoeften te voldoen.

Ontwikkelaars zouden wat rigoureuzer moeten zijn in hun ontwikkelstroom en aanbod changesets (bestand dat beschrijft welke bibliotheek hun code verandert, de ernst na de zeug conventie, en een beschrijving van de verandering). Deze changesets worden vervolgens gebruikt om automatisch de versie van de pakketten te verbeteren, met inachtneming van de gegeven ernst, en om het genereren van pakketten te automatiseren changelogs. Bovendien maken de tools dit mogelijk pre release modus, de 🍒 op de 🍰.

Wat is het volgende ?

Nadat we de tools hadden uitgekozen, was het tijd om aan de slag te gaan. In het volgende blogartikel zullen we het hebben over het bouwsysteem en alle dev-ops/automatisering/continue integratie in de context van een monorepository.


Valentin DE ALMEIDA
Ontwikkelaarservaring en kerntechnologie – Ledger Live

Tijdstempel:

Meer van Grootboek