Projekt Ledger Live Monorepo: 2. del – Orodja (Naj bo sijalo) | Ledger

Projekt Ledger Live Monorepo: 2. del – Orodja (Naj bo sijalo) | Ledger

Časovni žig: 28. november 2023 9:10
Izvorno vozlišče: 2985172

Drugi vnos serije objav v spletnem dnevniku »Projekt Ledger Live Monorepo«, kjer nam razvijalec Ledgerja pripoveduje zgodbo o ogromni selitvi kodne baze Ledger Live v mono repozitorij. Če ste zamudili 1. del, si ga oglejte tukaj:

Ko smo ugotovili, da je arhitektura monorepo izvedljiva rešitev, smo začeli preučevati razpoložljiva orodja za uvedbo našega načrta.

Vodenje več projektov

V skupini Ledger Live krmarimo po ekosistemu JavaScript in na našo srečo smo že poznali več načinov za upravljanje več projektov z našim upraviteljem paketov. Nekatere od teh možnih rešitev vključujejo:

  • NPM (ima podporo za delovne prostore, vendar boljše alternative),
  • Preja 1 (postanejo prestare, boljše in učinkovitejše alternative),
  • Preja ≥ 2 (zanimiva ideja, vendar plug n play ni dobro podprt povsod, zlasti z React Native),
  • PNPM (simbolične povezave, izdelane z mislijo na delovne prostore, učinkovito na disku).

Po ogledu vseh teh smo se odločili, da gremo z PNPM za:

  • učinkovitost diska (uporablja virtualni trgovina in simboli, tako da se paketi prenesejo samo enkrat, nato pa se iz virtualne trgovine povežejo z vašimi node_modules),
  • hitrost (ker so paketi predpomnjeni, so naslednje namestitve veliko hitrejše),
  • vgrajena podpora za arhitekturo delovnih prostorov/monorepo (vzdevki, orkestracija itd.).

Na papirju PNPM je absolutni dragulj, vendar so bile simbolne povezave nekoliko nenavadne pri pravilni nastavitvi (spet, posebej pri React Native).

V redu, torej smo se odločili, šli bi z njo PNPM.

Orkestracija scenarija

Čeprav PNPM dodaja vedno več orkestracije svojim funkcijam, še vedno ne pokriva vsega, kar smo želeli narediti, kot so:

  • zaporedne gradnje,
  • predpomnjenje.

Za te smo našli dva zanimiva kandidata, ki smo ju morali pogledati:

  • NX (od ekipe Angular),
  • Turborepo (ki je pravkar napovedal v1.0.0, ko smo začeli delati na njej in zdaj sodeluje z ekipo Vercel).

Na obeh smo opravili dokaz koncepta.

NX je imel veliko več funkcij, generatorjev, avtomatizacije, odličnih grafov odvisnosti itd., vendar je dodal veliko dodatnih stroškov in ker je precej samozavesten, bi morali slediti njihovim konvencijam.

Turborepo po drugi strani pa je precej osnovna funkcija. Vendar je to priročna rešitev plug and play, ki jo lahko zelo hitro spremenimo, če se pojavi potreba.

Čeprav Turborepo imel manj lastnosti kot NX, naredil je dve stvari, ki smo jih iskali:

  • Orkestracija gradenj ob upoštevanju drevesa odvisnosti (in sočasnih gradenj),
  • Predpomnjenje (zgradbe so predpomnjene in "ponovno predvajane", če se njihova koda ni spremenila).

Zaradi tega, poleg preprostega vstopa/izstopa, smo izbrali novega fanta v bloku, TurboRepo.

Različica

Preučili smo tudi več rešitev, vendar smo se na koncu odločili za uporabo https://github.com/changesets/changesets saj je bilo to orodje, ki ga je priporočal TurboRepo, in po kratkem branju dokumentacije se je zdelo, da ustreza našim potrebam.

Razvijalci bi morali biti nekoliko strožji pri razvoju in zagotavljanju changesets (datoteka, ki opisuje, katero knjižnico spremeni njihova koda, resnost, ki sledi sejati konvencija in opis spremembe). te changesets se nato uporabijo za samodejno spreminjanje različice paketov, ki upoštevajo dane resnosti, kot tudi za avtomatizacijo generiranja dnevniki sprememb. Poleg tega orodja omogočajo pre release načinu, 🍒 na 🍰.

Kaj je naslednje ?

Ko smo se odločili za orodja, je bil čas za začetek dela. V naslednjem članku v blogu bomo govorili o sistemu gradnje in vseh razvojnih operacijah/avtomatizaciji/neprekinjeni integraciji v kontekstu mono repozitorija.

Valentin DE ALMEIDA
Izkušnje razvijalcev in osnovna tehnologija – Ledger Live

Časovni žig:

Več od Ledger