Projekt Ledger Live Monorepo: Część 2 — Narzędzia (nadaj blasku) | Księga główna

Projekt Ledger Live Monorepo: Część 2 – Narzędzia (nadaj blasku) | Księga główna

Węzeł źródłowy: 2985172

Drugi wpis z serii wpisów na blogu „Ledger Live Monorepo Project”, w którym programista Ledger opowiada nam historię ogromnej migracji bazy kodu Ledger Live do repozytorium mono. Jeśli przegapiłeś część 1, zajrzyj tutaj:

Po ustaleniu, że architektura monorepo jest realnym rozwiązaniem, zaczęliśmy analizować dostępne narzędzia, aby wdrożyć nasz plan.

Obsługa wielu projektów

W zespole Ledger Live poruszamy się po ekosystemie JavaScript i na szczęście dla nas znaliśmy już kilka sposobów obsługi wielu projektów z naszym menadżerem pakietów. Niektóre z możliwych rozwiązań obejmują:

  • NPM (obsługuje obszary robocze, ale lepsze alternatywy),
  • Przędza 1 (starzenie się przestarzałych, lepszych i wydajniejszych alternatyw),
  • Przędza ≥ 2 (ciekawy pomysł, ale funkcja plug n play nie wszędzie jest dobrze obsługiwana, szczególnie w przypadku React Native),
  • PNP (dowiązania symboliczne, zbudowane z myślą o obszarach roboczych, wydajne na dysku).

Po obejrzeniu tego wszystkiego zdecydowaliśmy się pójść z PNP do:

  • wydajność dysku (wykorzystuje wirtualny sklep i dowiązania symboliczne, więc pakiety są pobierane tylko raz, a następnie dowiązywane symbolicznie do modułów node_modules z magazynu wirtualnego),
  • szybkość (ponieważ pakiety są buforowane, kolejne instalacje przebiegają znacznie szybciej),
  • wbudowana obsługa obszarów roboczych/architektury monorepo (aliasy, orkiestracja itp.).

Na papierze PNP jest absolutną perełką, ale dowiązania symboliczne były nieco dziwne przy prawidłowej konfiguracji (ponownie, szczególnie w przypadku React Native).

Ok, więc dokonaliśmy wyboru i pójdziemy z nim PNP.

Orkiestracja skryptu

Nawet jeśli PNP dodaje coraz więcej orkiestracji do swoich funkcji, ale nadal nie obejmuje wszystkiego, co chcieliśmy zrobić, na przykład:

  • kompilacje sekwencyjne,
  • buforowanie.

W tym celu znaleźliśmy dwóch interesujących kandydatów, którym musieliśmy się przyjrzeć:

  • NX (przez zespół kątowy),
  • Turborepo (który właśnie ogłosił wersję 1.0.0, kiedy zaczęliśmy nad nią pracować, a teraz współpracujemy z zespołem Vercel).

Zrobiliśmy weryfikację koncepcji w obu przypadkach.

NX miał znacznie więcej funkcji, generatorów, automatyzacji, świetnych wykresów zależności itp., ale dodało to dużo kosztów ogólnych, a ponieważ jest dość opiniotwórczy, musielibyśmy przestrzegać ich konwencji.

Turborepo z drugiej strony jest to dość podstawowa funkcja, jeśli chodzi o funkcje. Jest to jednak wygodne rozwiązanie typu plug and play, które możemy bardzo szybko zmienić, jeśli zajdzie taka potrzeba.

Nawet jeśli Turborepo miał mniej funkcji niż NX, zrobił 2 rzeczy, których szukaliśmy:

  • Orkiestracja kompilacji z uwzględnieniem drzewa zależności (i kompilacji współbieżnych),
  • Buforowanie (kompilacje są buforowane i „odtwarzane”, jeśli ich kod się nie zmienił).

To, plus łatwe dołączenie/wycofanie się, sprawiło, że wybraliśmy nowego dzieciaka w okolicy, TurboRepo.

Wersja

Rozważaliśmy również kilka rozwiązań, ale ostatecznie zdecydowaliśmy się na zastosowanie https://github.com/changesets/changesets ponieważ było to jedno z narzędzi polecanych przez TurboRepo i po krótkim przeczytaniu dokumentacji wydawało się odpowiadać naszym potrzebom.

Deweloperzy musieliby być nieco bardziej rygorystyczni w zakresie przepływu pracy i zapewniania changesets (plik opisujący bibliotekę, w której zmienia się ich kod, ważność zgodnie z semwer konwencję i opis zmiany). Te changesets są następnie wykorzystywane do automatycznego podbijania wersji pakietów z uwzględnieniem podanej ważności, a także automatyzowania generowania dzienniki zmian. Co więcej, narzędzia na to pozwalają pre release tryb, 🍒 na 🍰.

Co dalej ?

Po wybraniu narzędzi przyszedł czas na pracę. W następnym artykule na blogu porozmawiamy o systemie kompilacji i wszystkich procesach deweloperskich/automatyzacji/ciągłej integracji w kontekście repozytorium mono.


Valentina DE ALMEIDA
Doświadczenie programisty i podstawowa technologia – Ledger Live

Znak czasu:

Więcej z Księga główna