Ledger Live Monorepo Project: Del 2 - Verktøyene (Make it Shine) | Ledger

Ledger Live Monorepo Project: Del 2 – Verktøyene (Make it Shine) | Ledger

Tidsstempel: 28. november 2023, kl
Kilde node: 2985172

Andre oppføring i blogginnleggsserien "Ledger Live Monorepo Project", der en Ledger-utvikler forteller oss historien om Ledger Live-kodebasens enorme migrering til et mono-repository. Hvis du gikk glipp av del 1, sjekk den ut her:

Etter å ha fastslått at en monorepo-arkitektur var en levedyktig løsning, begynte vi å se på tilgjengelige verktøy for å få på plass planen vår.

Håndtere flere prosjekter

I Ledger Live-teamet navigerer vi i JavaScript-økosystemet, og heldigvis for oss visste vi allerede om flere måter å håndtere flere prosjekter på med pakkebehandleren vår. Noen av de mulige løsningene inkluderer:

  • NPM (har støtte for arbeidsområder, men bedre alternativer),
  • Garn 1 (bli for gammel, bedre og mer effektive alternativer),
  • Garn ≥ 2 (interessant idé, men plug n play støttes ikke godt overalt, spesielt med React Native),
  • PNPM (symbolkoblinger, bygget med tanke på arbeidsområder, diskeffektiv).

Etter å ha sett på alle disse, bestemte vi oss for å gå med PNPM for:

  • diskeffektiviteten (den bruker en virtuell oppbevare og symlenker, så pakker lastes ned bare én gang og deretter symlinked til node_modules fra den virtuelle butikken),
  • hastigheten (siden pakker er bufret, er påfølgende installasjoner mye raskere),
  • innebygd støtte for arbeidsområder/monorepo-arkitektur (aliaser, orkestrering osv...).

På papir PNPM er en absolutt perle, men symbolske lenker var litt rart å sette opp riktig (igjen, spesielt med React Native).

Ok, så vårt valg ble tatt, vi ville gå med PNPM.

Manusorkestering

Selv om PNPM legger til mer og mer orkestrering til funksjonene, den dekker fortsatt ikke alt vi ønsket å gjøre, for eksempel:

  • sekvensielle bygg,
  • caching.

For disse fant vi to interessante utfordrere som vi trengte å ta en titt på:

  • NX (av det kantete laget),
  • Turborepo (som nettopp annonserte v1.0.0 da vi begynte å jobbe med den, og nå jobber med Vercel-teamet).

Vi gjorde et proof of concept på begge.

NX hadde mye flere funksjoner, generatorer, automatisering, flotte avhengighetsgrafer osv... men det la til mye overhead, og siden det er ganske selvstendig, måtte vi følge deres konvensjoner.

Turborepo på den annen side, er ganske grunnleggende funksjonsmessig. Likevel er det en praktisk plug and play-løsning som vi kan endre veldig raskt hvis behovet skulle komme.

Selv om Turborepo hadde færre funksjoner enn NX, den gjorde de 2 tingene vi lette etter:

  • Orkestrering av bygg som respekterer avhengighetstreet (og samtidige bygg),
  • Bufring (builds bufres og "spilles på nytt" hvis koden deres ikke er endret).

Det, pluss den enkle drop-in / drop-out, fikk oss til å velge den nye ungen på blokken, TurboRepo.

versjons~~POS=TRUNC

Vi så på flere løsninger også, men bestemte oss til slutt for å bruke https://github.com/changesets/changesets ettersom det var ett verktøy som TurboRepo anbefalte, og etter litt dokumentasjonslesing så det ut til å samsvare med våre behov.

Utviklere må være litt mer strenge i utviklingsflyten og tilby changesets (fil som beskriver hvilket bibliotek koden deres endres, alvorlighetsgraden etter purke konvensjon og en beskrivelse av endringen). Disse changesets brukes deretter til å automatisk bumpe versjonen av pakkene som respekterer de gitte alvorlighetsgradene, samt automatisere genereringen av Endrings. På toppen av det gir verktøyene rom for pre release modus, 🍒 på 🍰.

Hva blir det neste ?

Etter å ha bestemt seg for verktøyene, var det på tide å begynne å jobbe. I den neste bloggartikkelen vil vi snakke om byggesystemet og alle dev-ops / automatisering / kontinuerlig integrasjon i sammenheng med et mono-repository.

Valentin DE ALMEIDA
Utviklererfaring og kjerneteknologi – Ledger Live

Tidstempel:

Mer fra Ledger