Ledger Live Monorepo Project: Del 2 - Verktygen (Make it Shine) | Huvudbok

Ledger Live Monorepo Project: Del 2 – Verktygen (Make it Shine) | Huvudbok

Tidsstämpel: 28 november 2023 9:10
Källnod: 2985172

Andra inlägget i blogginläggsserien "Ledger Live Monorepo Project", där en Ledger-utvecklare berättar historien om Ledger Live-kodbasens enorma migrering till ett monolager. Om du missade del 1, kolla in den här:

Efter att ha konstaterat att en monorepo-arkitektur var en genomförbar lösning började vi titta på de tillgängliga verktygen för att införa vår plan.

Hantera flera projekt

I Ledger Live-teamet navigerar vi i JavaScript-ekosystemet, och lyckligtvis för oss kände vi redan till flera sätt att hantera flera projekt med vår pakethanterare. Några av dessa möjliga lösningar inkluderar:

  • NPM (har stöd för arbetsytor men bättre alternativ),
  • Garn 1 (blir för gammal, bättre och effektivare alternativ),
  • Garn ≥ 2 (intressant idé, men plug n play stöds inte överallt, särskilt med React Native),
  • PNPM (symbollänkar, byggda med arbetsytor i åtanke, diskeffektiv).

Efter att ha tittat på alla dessa, bestämde vi oss för att gå med PNPM för:

  • diskeffektiviteten (den använder en virtuell lagra och symlinks, så paket laddas bara ner en gång och länkas sedan till dina node_modules från den virtuella butiken),
  • hastigheten (eftersom paket cachelagras är efterföljande installationer mycket snabbare),
  • inbyggt stöd för arbetsytor/monorepo-arkitektur (alias, orkestrering etc...).

På papper PNPM är en absolut pärla, men symboliska länkar var lite udda att ställa in korrekt (igen, speciellt med React Native).

Ok, så vårt val var gjort, vi skulle följa med PNPM.

Manusorkestrering

Även om PNPM lägger till mer och mer orkestrering till dess funktioner, det täcker fortfarande inte allt vi ville göra, till exempel:

  • sekventiell konstruktion,
  • cachning.

För dessa hittade vi två intressanta utmanare som vi behövde ta en titt på:

  • NX (av det kantiga laget),
  • Turborepo (som precis tillkännagav v1.0.0 när vi började arbeta med den, och nu arbetar med Vercel-teamet).

Vi gjorde en proof of concept på båda.

NX hade mycket fler funktioner, generatorer, automation, fantastiska beroendegrafer etc... men det tillförde en hel del overhead, och eftersom det är ganska egensinnigt, måste vi följa deras konventioner.

Turborepo å andra sidan, är ganska grundläggande funktion klokt. Ändå är det en bekväm plug and play-lösning som vi skulle kunna ändra mycket snabbt om behovet uppstår.

Även om Turborepo hade färre funktioner än NX, den gjorde de 2 sakerna vi letade efter:

  • Orkestering av byggnader som respekterar beroendeträdet (och samtidiga byggnader),
  • Cachning (byggnader cachelagras och "spelas om" om deras kod inte har ändrats).

Det, plus det enkla in- och avhoppet, fick oss att välja det nya barnet på kvarteret, TurboRepo.

versionshantering

Vi tittade också på flera lösningar, men valde till slut att använda dem https://github.com/changesets/changesets eftersom det var ett verktyg som TurboRepo rekommenderade, och efter lite dokumentationsläsning verkade det uppfylla våra behov.

Utvecklare skulle behöva vara lite mer rigorösa i sitt utvecklingsflöde och tillhandahålla changesets (fil som beskriver vilket bibliotek deras kod ändras, svårighetsgraden efter sugga konvention och en beskrivning av förändringen). Dessa changesets används sedan för att automatiskt bumpa versionen av paketen som respekterar de givna svårighetsgraderna, samt automatisera genereringen av ändringsloggar. Utöver det tillåter verktygen pre release läge, 🍒 på 🍰.

Vad kommer härnäst ?

Efter att ha bestämt sig för verktygen var det dags att börja jobba. I nästa bloggartikel kommer vi att prata om byggsystemet och alla dev-ops/automatisering/kontinuerlig integration i samband med ett mono-förråd.

Valentin DE ALMEIDA
Utvecklarerfarenhet & Core Tech – Ledger Live

Tidsstämpel:

Mer från Ledger