Progetto Ledger Live Monorepo: Parte 2 – Gli strumenti (Make it Shine) | Registro

Seconda voce della serie di post del blog "Ledger Live Monorepo Project", in cui uno sviluppatore Ledger ci racconta la storia dell'enorme migrazione della base di codice Ledger Live in un repository mono. Se ti sei perso la prima parte, dai un'occhiata qui:

Dopo aver stabilito che un'architettura monorepo era una soluzione praticabile, abbiamo iniziato a esaminare gli strumenti disponibili per mettere in atto il nostro piano.

Gestire più progetti

Nel team di Ledger Live navighiamo nell'ecosistema JavaScript e, fortunatamente per noi, conoscevamo già diversi modi per gestire più progetti con il nostro gestore di pacchetti. Alcune di queste possibili soluzioni includono:

• NPM (ha supporto per gli spazi di lavoro ma alternative migliori),
• Filato 1 (diventando troppo vecchi, alternative migliori e più efficienti),
• Filato ≥ 2 (idea interessante, ma plug n play non ben supportato ovunque, specialmente con React Native),
• PNPM (link simbolici, creati pensando agli spazi di lavoro, efficienti sul disco).

Dopo aver esaminato tutto ciò, abbiamo deciso di procedere PNPM per:

• l'efficienza del disco (usa un virtual Tornare al suo account ed collegamenti simbolici, quindi i pacchetti vengono scaricati solo una volta e poi collegati simbolicamente ai tuoi node_modules dal negozio virtuale),
• la velocità (poiché i pacchetti vengono memorizzati nella cache, le installazioni successive sono molto più veloci),
• supporto integrato per spazi di lavoro/architettura monorepo (alias, orchestrazione ecc…).

Sulla carta PNPM è un vero gioiello, ma i collegamenti simbolici erano un po' strani da impostare correttamente (di nuovo, specialmente con React Native).

Ok, quindi la nostra scelta è stata fatta, vorremmo andare avanti PNPM.

Orchestrazione degli script

Sebbene PNPM aggiunge sempre più orchestrazione alle sue funzionalità, ma non copre ancora tutto ciò che volevamo fare, come ad esempio:

• build sequenziali,
• memorizzazione nella cache.

Per questi, abbiamo trovato due contendenti interessanti a cui dovevamo dare un'occhiata:

• NX (dal team angolare),
• Turborepo (che ha appena annunciato la versione 1.0.0 quando abbiamo iniziato a lavorarci, e ora lavora con il team Vercel).

Abbiamo fatto una prova di concetto su entrambi.

NX aveva molte più funzionalità, generatori, automazione, ottimi grafici delle dipendenze ecc... ma aggiungeva molto sovraccarico e, poiché è piuttosto supponente, avremmo dovuto seguire le loro convenzioni.

Turborepo d'altra parte, è piuttosto semplice dal punto di vista delle funzionalità. Eppure è una comoda soluzione plug and play che potremmo cambiare molto rapidamente se mai se ne presentasse la necessità.

Sebbene Turborepo aveva meno funzionalità di NX, ha fatto le 2 cose che stavamo cercando:

• Orchestrazione di build rispettando l'albero delle dipendenze (e build simultanee),
• Caching (le build vengono memorizzate nella cache e "riprodotte" se il loro codice non è cambiato).

Questo, oltre al facile accesso/abbandono, ci ha fatto scegliere il nuovo ragazzo del quartiere, TurboRepo.

versioning

Abbiamo esaminato anche diverse soluzioni, ma alla fine abbiamo deciso di utilizzarle https://github.com/changesets/changesets poiché era uno strumento consigliato da TurboRepo e, dopo un po' di lettura della documentazione, sembrava soddisfare le nostre esigenze.

Gli sviluppatori dovrebbero essere un po' più rigorosi nel flusso di sviluppo e nella fornitura changesets (file che descrive quale libreria cambia il loro codice, la gravità seguente sempre convenzione e una descrizione della modifica). Questi changesets vengono poi utilizzati per eseguire il bumping automatico della versione dei pacchetti rispettando la gravità specificata, nonché per automatizzare la generazione dei file changelog. Inoltre, gli strumenti lo consentono pre release modalità, il 🍒 sul 🍰.

Qual è il prossimo?

Dopo aver deciso gli strumenti, era ora di iniziare a lavorare. Nel prossimo articolo del blog parleremo del sistema di build e di tutte le operazioni di sviluppo/automazione/integrazione continua nel contesto di un repository mono.

---

Valentin DE ALMEIDA
Esperienza dello sviluppatore e tecnologia di base: Ledger Live

• Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
• PlatoData.Network Generativo verticale Ai. Potenzia te stesso. Accedi qui.
• PlatoAiStream. Intelligenza Web3. Conoscenza amplificata. Accedi qui.
• PlatoneESG. Carbonio, Tecnologia pulita, Energia, Ambiente, Solare, Gestione dei rifiuti. Accedi qui.
• Platone Salute. Intelligence sulle biotecnologie e sulle sperimentazioni cliniche. Accedi qui.
• Fonte: https://www.ledger.com/blog/ledger-live-monorepo-project-part-2-the-tools-make-it-shine