Ledger Live Monorepo Project: Del 2 - Værktøjerne (Make it Shine) | Hovedbog

Ledger Live Monorepo Project: Del 2 – Værktøjerne (Make it Shine) | Hovedbog

Tidsstempel: 28. november 2023 kl. 9
Kildeknude: 2985172

Anden indgang i blogindlægsserien "Ledger Live Monorepo Project", hvor en Ledger-udvikler fortæller os historien om Ledger Live-kodebasens enorme migration til et mono-lager. Hvis du gik glip af del 1, så tjek den ud her:

Efter at have fastslået, at en monorepo-arkitektur var en levedygtig løsning, begyndte vi så at undersøge de tilgængelige værktøjer til at implementere vores plan.

Håndtering af flere projekter

I Ledger Live-teamet navigerer vi i JavaScript-økosystemet, og heldigvis for os kendte vi allerede til flere måder at håndtere flere projekter på med vores pakkeadministrator. Nogle af disse mulige løsninger omfatter:

  • NPM (har understøttelse af arbejdsområder, men bedre alternativer),
  • Garn 1 (at blive for gammel, bedre og mere effektive alternativer),
  • Garn ≥ 2 (interessant idé, men plug n play understøttes ikke godt overalt, især med React Native),
  • PNPM (Symlinks, bygget med arbejdsområder i tankerne, diskeffektiv).

Efter at have set på alle disse, besluttede vi at gå med PNPM for:

  • diskeffektiviteten (den bruger en virtuel butik , symlinks, så pakker downloades kun én gang og derefter symlinket til dine node_modules fra den virtuelle butik),
  • hastigheden (da pakker er cachelagret, er efterfølgende installationer meget hurtigere),
  • indbygget understøttelse af arbejdsområder/monorepo-arkitektur (aliaser, orkestrering osv...).

På papir PNPM er en absolut perle, men symbolske links var lidt mærkelige at konfigurere korrekt (igen, specielt med React Native).

Ok, så vores valg var taget, ville vi gå med PNPM.

Manuskriptorkestering

Selvom PNPM tilføjer mere og mere orkestrering til dets funktioner, det dækker stadig ikke alt, hvad vi ønskede at gøre, såsom:

  • sekventielle builds,
  • cachelagring.

Til disse fandt vi to interessante kandidater, som vi skulle tage et kig på:

  • NX (af det kantede hold),
  • Turborepo (som netop annoncerede v1.0.0, da vi begyndte at arbejde på det, og nu arbejder med Vercel-teamet).

Vi lavede et proof of concept på begge.

NX havde meget flere funktioner, generatorer, automatisering, fantastiske afhængighedsgrafer osv.. men det tilføjede en masse overhead, og da det er ret opsigtsvækkende, skulle vi følge deres konventioner.

Turborepo på den anden side er ret grundlæggende funktionsmæssigt. Alligevel er det en praktisk plug and play-løsning, som vi kunne ændre meget hurtigt, hvis behovet opstår.

Selvom Turborepo havde færre funktioner end NX, den gjorde de 2 ting, vi ledte efter:

  • Orkestrering af builds, der respekterer afhængighedstræet (og samtidige builds),
  • Caching (builds cachelagres og 'afspilles igen', hvis deres kode ikke er ændret).

Det, plus det nemme drop-in / drop-out, fik os til at vælge det nye barn på blokken, TurboRepo.

Versionering

Vi undersøgte også flere løsninger, men besluttede i sidste ende at bruge dem https://github.com/changesets/changesets da det var et værktøj, som TurboRepo anbefalede, og efter lidt dokumentationslæsning syntes det at være i overensstemmelse med vores behov.

Udviklere skal være lidt mere strenge i deres udviklingsflow og levere changesets (fil, der beskriver, hvilket bibliotek deres kode ændres, sværhedsgraden efter så konvention og en beskrivelse af ændringen). Disse changesets bruges derefter til automatisk at bumpe versionen af ​​pakkerne, der respekterer de givne sværhedsgrader, samt automatisere genereringen af ændringslogs. Oven i købet giver værktøjerne mulighed for pre release tilstand, 🍒 på 🍰.

Hvad er det næste?

Efter at have besluttet sig for værktøjerne, var det tid til at begynde at arbejde. I den næste blogartikel vil vi tale om byggesystemet og alle dev-ops / automatisering / kontinuerlig integration i sammenhæng med et mono-lager.

Valentin DE ALMEIDA
Developer Experience & Core Tech – Ledger Live

Tidsstempel:

Mere fra Ledger