Ledger Live Monorepo -projekti: Osa 2 - Työkalut (Make it Shine) | Ledger

Ledger Live Monorepo -projekti: Osa 2 – Työkalut (Make it Shine) | Ledger

Aikaleima: 28. marraskuuta 2023 9
Lähdesolmu: 2985172

Toinen blogitekstisarjan "Ledger Live Monorepo Project" merkintä, jossa Ledger-kehittäjä kertoo meille tarinan Ledger Live -koodikannan valtavasta siirtymisestä monoarkistoon. Jos unohdat osan 1, katso se täältä:

Todettuamme, että monorepo-arkkitehtuuri oli toteuttamiskelpoinen ratkaisu, aloimme sitten tutkia käytettävissä olevia työkaluja suunnitelmamme toteuttamiseksi.

Useiden projektien käsittely

Ledger Live -tiimissä navigoimme JavaScript-ekosysteemissä, ja onneksi tiesimme jo useita tapoja käsitellä useita projekteja pakettihallinnan avulla. Joitakin näistä mahdollisista ratkaisuista ovat:

  • NPM (tukee työtiloja, mutta parempia vaihtoehtoja),
  • Lanka 1 (tulevat liian vanhoiksi, parempia ja tehokkaampia vaihtoehtoja),
  • Lanka ≥ 2 (mielenkiintoinen idea, mutta plug n play -toimintoa ei tueta hyvin kaikkialla, etenkään React Nativessa),
  • PNPM (symlinkit, rakennettu työtiloja ajatellen, levytehokas).

Kaikkien näiden tarkastelun jälkeen päätimme lähteä mukaan PNPM varten:

  • levyn tehokkuus (se käyttää virtuaalista verkkokaupasta ja symlinkkejä, joten paketit ladataan vain kerran ja sitten ne linkitetään virtuaalikaupasta node_modules-tiedostoosi),
  • nopeus (koska paketit tallennetaan välimuistiin, seuraavat asennukset ovat paljon nopeampia),
  • sisäänrakennettu tuki työtiloille/monorepo-arkkitehtuurille (aliakset, orkestrointi jne.).

Paperilla PNPM on ehdoton helmi, mutta symlinkit olivat hieman oudosti asennettuina oikein (jälleen, erityisesti React Nativen kanssa).

Ok, valintamme oli tehty, menisimme mukaan PNPM.

Käsikirjoituksen orkestrointi

Vaikka PNPM lisää ja lisää orkestrointia sen ominaisuuksiin, se ei silti kata kaikkea, mitä halusimme tehdä, kuten:

  • peräkkäiset rakennukset,
  • välimuisti.

Löysimme näitä varten kaksi mielenkiintoista haastajaa, joita meidän piti tarkastella:

  • NX (kulmatiimin toimesta),
  • Turborepo (joka julkisti juuri v1.0.0:n, kun aloimme työskennellä sen parissa, ja nyt työskentelemme Vercel-tiimin kanssa).

Teimme konseptitodistuksen molemmille.

NX siinä oli paljon enemmän ominaisuuksia, generaattoreita, automaatiota, suuria riippuvuuskaavioita jne., mutta se lisäsi paljon yleiskustannuksia, ja koska se on melko mielivaltainen, meidän olisi noudatettava niiden käytäntöjä.

Turborepo toisaalta on melko perusominaisuuksia. Se on kuitenkin kätevä plug and play -ratkaisu, jonka voisimme muuttaa erittäin nopeasti, jos tarvetta ilmenee.

Vaikka Turborepo oli vähemmän ominaisuuksia kuin NX, se teki kaksi etsimäämme asiaa:

  • Koonnosten orkestrointi riippuvuuspuuta kunnioittaen (ja samanaikaiset koonnokset),
  • Välimuisti (versiot tallennetaan välimuistiin ja "toistetaan", jos niiden koodi ei ole muuttunut).

Tämä sekä helppo pudotus / pudotus sai meidät valitsemaan uuden lapsen korttelille, TurboRepo.

versiointi

Tutkimme myös useita ratkaisuja, mutta päätimme lopulta käyttää https://github.com/changesets/changesets koska se oli yksi TurboRepon suosittelema työkalu, ja pienen dokumentaation lukemisen jälkeen näytti vastaavan tarpeitamme.

Kehittäjien tulee olla hieman tiukempi kehityskulkunsa ja tarjonnan suhteen changesets (tiedosto, joka kuvaa, mikä kirjasto heidän koodinsa muuttuu, vakavuus, joka seuraa kylvää yleissopimus ja kuvaus muutoksesta). Nämä changesets käytetään sitten automaattisesti lyömään pakettien versiot, jotka noudattavat annettuja vakavuusasteita, sekä automatisoimaan pakettien luomisen. muutoslokien. Lisäksi työkalut mahdollistavat pre release tila, 🍒 päällä 🍰.

Mitä seuraavaksi ?

Työkalujen valinnan jälkeen oli aika aloittaa työskentely. Seuraavassa blogiartikkelissa puhumme rakennusjärjestelmästä ja kaikista kehittäjistä / automaatiosta / jatkuvasta integraatiosta monoarkiston yhteydessä.

Valentin DE ALMEIDA
Kehittäjäkokemus ja ydintekniikka – Ledger Live

Aikaleima:

Lisää aiheesta pääkirja