Zweiter Eintrag der Blog-Beitragsreihe „Ledger Live Monorepo Project“, in der uns ein Ledger-Entwickler die Geschichte der riesigen Migration der Ledger Live-Codebasis in ein Mono-Repository erzählt. Wenn Sie Teil 1 verpasst haben, schauen Sie sich ihn hier an:

Nachdem wir festgestellt hatten, dass eine Monorepo-Architektur eine praktikable Lösung war, begannen wir, die verfügbaren Tools zur Umsetzung unseres Plans zu prüfen.

Bearbeitung mehrerer Projekte

Im Ledger Live-Team navigieren wir im JavaScript-Ökosystem und zum Glück kannten wir bereits mehrere Möglichkeiten, mehrere Projekte mit unserem Paketmanager abzuwickeln. Einige dieser möglichen Lösungen umfassen:

• NPM (hat Unterstützung für Arbeitsbereiche, aber bessere Alternativen),
• Garn 1 (Überalterung, bessere und effizientere Alternativen),
• Garn ≥ 2 (interessante Idee, aber Plug-and-Play wird nicht überall gut unterstützt, insbesondere mit React Native),
• PNPM (Symlinks, speziell für Arbeitsbereiche erstellt, speichereffizient).

Nachdem wir uns das alles angeschaut hatten, entschieden wir uns dafür PNPM für:

• die Festplatteneffizienz (es wird eine virtuelle verwendet speichern und Symlinks, sodass Pakete nur einmal heruntergeladen und dann aus dem virtuellen Store mit Ihren node_modules verknüpft werden.
• die Geschwindigkeit (da Pakete zwischengespeichert werden, sind nachfolgende Installationen viel schneller),
• Integrierte Unterstützung für Arbeitsbereiche/Monorepo-Architektur (Aliase, Orchestrierung usw.).

Auf Papier PNPM ist ein absolutes Juwel, aber die korrekte Einrichtung von Symlinks war etwas seltsam (wiederum, insbesondere mit React Native).

Ok, unsere Entscheidung war also getroffen, wir würden mitmachen PNPM.

Skript-Orchestrierung

Obwohl PNPM fügt seinen Funktionen immer mehr Orchestrierung hinzu, deckt aber immer noch nicht alles ab, was wir tun wollten, wie zum Beispiel:

• sequentielle Builds,
• zwischenspeichern.

Hierfür haben wir zwei interessante Kandidaten gefunden, die wir uns unbedingt ansehen sollten:

• NX (vom Angular-Team),
• Turborepo (das gerade die Version 1.0.0 angekündigt hat, als wir mit der Arbeit daran begonnen haben und jetzt mit dem Vercel-Team zusammenarbeiten).

Wir haben für beide einen Proof of Concept durchgeführt.

NX hatte viel mehr Funktionen, Generatoren, Automatisierung, tolle Abhängigkeitsdiagramme usw., aber es verursachte viel Overhead, und da es ziemlich eigensinnig ist, mussten wir deren Konventionen befolgen.

Turborepo Auf der anderen Seite handelt es sich um recht einfache Funktionen. Dennoch handelt es sich um eine praktische Plug-and-Play-Lösung, die wir bei Bedarf sehr schnell ändern können.

Obwohl Turborepo hatte weniger Funktionen als NX, es hat die 2 Dinge getan, nach denen wir gesucht haben:

• Orchestrierung von Builds unter Berücksichtigung des Abhängigkeitsbaums (und gleichzeitiger Builds),
• Caching (Builds werden zwischengespeichert und „wiedergegeben“, wenn sich ihr Code nicht geändert hat).

Das und das einfache Ein- und Aussteigen haben uns dazu bewogen, uns für den Neuzugang in der Gegend zu entscheiden. TurboRepo.

Versionierung

Wir haben auch mehrere Lösungen geprüft, uns aber letztendlich für die Verwendung entschieden https://github.com/changesets/changesets Da es sich um ein von TurboRepo empfohlenes Tool handelte, schien es nach einigem Lesen der Dokumentation unseren Anforderungen zu entsprechen.

Entwickler müssten ihren Entwicklungsablauf und ihre Bereitstellung etwas strenger gestalten changesets (Datei beschreibt, welche Bibliothek ihr Code ändert, der Schweregrad folgt dem halbwegs Konvention und eine Beschreibung der Änderung). Diese changesets werden dann verwendet, um die Version der Pakete automatisch unter Berücksichtigung der angegebenen Schweregrade zu aktualisieren und die Generierung zu automatisieren Changelogs. Darüber hinaus ermöglichen die Tools pre release Modus, das 🍒 auf dem 🍰.

Was kommt als nächstes?

Nachdem wir uns für die Werkzeuge entschieden hatten, konnte es mit der Arbeit beginnen. Im nächsten Blogartikel werden wir über das Build-System und alle Dev-Ops/Automatisierung/Continuous Integration im Kontext eines Mono-Repositorys sprechen.

Valentin DE ALMEIDA
Entwicklererfahrung und Kerntechnologie – Ledger Live

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• PlatoData.Network Vertikale generative KI. Motiviere dich selbst. Hier zugreifen.
• PlatoAiStream. Web3-Intelligenz. Wissen verstärkt. Hier zugreifen.
• PlatoESG. Kohlenstoff, CleanTech, Energie, Umwelt, Solar, Abfallwirtschaft. Hier zugreifen.
• PlatoHealth. Informationen zu Biotechnologie und klinischen Studien. Hier zugreifen.
• Quelle: https://www.ledger.com/blog/ledger-live-monorepo-project-part-2-the-tools-make-it-shine