JavaScript >> Javascript-Tutorial >  >> Tags >> npm

pnpm und paketbasiertes Monorepo

Das Problem

Ich habe in der Vergangenheit mehrere Möglichkeiten ausprobiert, JavaScript/TypeScript Library Monorepos zu verwalten:lerna , yarn workspaces usw.

Verstehen Sie mich jetzt nicht falsch:Dies sind großartige Tools, und ich schätze die Mühe, die ihre Autoren in sie gesteckt haben, sehr.

Aber sie fühlten sich immer ein bisschen wie Glücksspiel an. Es fühlte sich nie so an, als hätte ich wirklich die Kontrolle über das, was passiert (mit viel schwarzer Magie), und ich fand, dass sie sich ein bisschen ... zerbrechlich anfühlten (ich war immer besorgt, einige Symlinks oder ähnliches zu brechen, wenn ich welche ausführte Befehle).

Eine Lösung?

Ich wollte beide pnpm ausprobieren und Paket. Ich hatte viel Gutes über beide Tools gehört und war in letzter Zeit immer frustrierter über ihre etablierteren Konkurrenten.

Als ich mir ihre jeweiligen Dokumentationsseiten ansah, sah es so aus, als hätten beide eine großartige Monorepo-Unterstützung. Da ich auch noch lange auf der Suche nach einer „Building an npm library“-kompatiblen Monorepo-Lösung war, die eine bessere Entwicklererfahrung bietet als das, was ich bisher gesehen habe, habe ich beschlossen, es auszuprobieren.

Das Repository

Also habe ich ein Test-Repository erstellt (und dokumentiert), um dieses neue Monorepo-Setup auszuprobieren:

pnpm &parcel Monorepo-Test

Ein Repository zum Ausprobieren einer Monorepo-Einrichtung einer JS/TS-npm-Bibliothek mit pnpm als Paketmanager und parcel als Build-Tool.

Entwicklungsvoraussetzungen:

  • Knoten v16+
  • PNM

Tech-Stack

Dies ist ein Überblick über die wichtigsten Komponenten des Tech-Stacks dieses Monorepos

  • pnpm -- Paket- und Monorepo-Arbeitsbereichsmanager
  • Paket -- Build-Tool
  • Scherz / ts-jest -- Unit-Testing-Framework
  • TypeScript / tsc -- TypeScript-Typprüfung
  • TypeScript ESLint -- Fusseln
  • Schöner -- Code-Formatierer
  • fliegdoc -- Dokumentationsgenerator
  • GitHub-Aktionen -- CI-Pipeline
  • Renovieren -- Verwaltung von Abhängigkeitsaktualisierungen

Verwendung

Einrichten der Entwicklungsumgebung

Installieren Sie die Abhängigkeiten:

pnpm install
  • läuft automatisch rekursiv für den Arbeitsbereich, vgl. https://pnpm.io/cli/install
  • Alias:pnpm i
  • npm ci -Äquivalent:pnpm i --frozen-lockfile (in CI-Umgebung automatisch wahr)

Sie können auch pnpm install ausführen wenn etwas über Ihre Abhängigkeiten veraltet ist, um es wieder zu reparieren.

Abhängigkeitsverwaltung

Installieren

… Auf GitHub ansehen

Das Repository enthält ein Test-Setup mit einem mehr oder weniger vollständigen Tech-Stack, der unter anderem besteht aus:

  • TypeScript
  • ESLint
  • Hübscher
  • fliegdoc (ein selbstgebauter Dokumentationsgenerator)
  • Scherz / ts-Scherz
  • GitHub-Aktionen

Das meiste habe ich im README.md beschrieben , aber ich habe auch eine zusätzliche öffentliche Notion-Seite erstellt, auf der weitere Details beschrieben werden.

Ergebnisse

Ich bin sehr zufrieden damit, wie es funktioniert, und werde diesen Ansatz in Zukunft definitiv verwenden. Ich werde in Zukunft wahrscheinlich auch bestehende Monorepos auf diesen Ansatz migrieren.

Vorteile

  • 🟢 Du fühlst dich, als hättest du die Kontrolle mit pnpm , es ist ziemlich einfach zu verstehen, wie ihr Workspace-System funktioniert, sodass Sie das Gefühl haben, die Kontrolle zu haben und nicht über Lösungen für Ihre Probleme raten müssen 🎉. Beispiel:pnpm install richtet alles ein. Vorher war ich immer unsicher, ob ich jetzt npm install ausführen soll , lerna bootstrap , oder etwas anderes.
  • 🟢 schnelle Bauzeiten seit parcel baut alle Pakete auf einmal (anstatt Build-Skripte einzeln auszuführen), die Build-Zeiten (insbesondere mit dem Build-Cache an Ort und Stelle) sind unglaublich schnell
  • 🟢 Entwicklungserfahrung mit parcel watch , kann man sich sehr schnell weiterentwickeln
  • 🟢 "native" Arbeitsbereiche Das Arbeiten mit Arbeitsbereichen / mehreren Paketen fühlt sich für pnpm "nativ" an (im Vergleich zu seinen Konkurrenten, bei denen ich leider festgestellt habe, dass es sich eher wie ein "hacky side feature" anfühlt). Befehle funktionieren so, wie ich es erwarten würde, "interne" Abhängigkeiten zwischen Paketen werden beim Veröffentlichen automatisch mit Versionsnummern versehen und so weiter.

Nachteile

Natürlich hat jeder Ansatz ein paar Nachteile. Hier sind die, die ich bisher gefunden habe:

  • 🟡 weniger Ökosystemunterstützung während pnpm und parcel funktionieren in 99 % der Fälle hervorragend, Tools testen ihre Unterstützung für diese oft nicht so sehr wie beispielsweise für yarn und webpack
  • 🟢 (keine Dependabot-Unterstützung) zum Zeitpunkt des Verfassens dieses Artikels der Dependabot von GitHub unterstützt pnpm nicht . Glücklicherweise scheint Renovate gut zu funktionieren.
  • 🟢 (keine enthaltenen "Release-Automatisierung"-Tools) lerna kam mit großartigen Changelog / Conventional Commit / ...-basierten Release-Automatisierungstools. Leider habe ich noch keine großartige Lösung gefunden, um etwas Ähnliches mit pnpm zu machen . Haben Sie Empfehlungen?

Eine schnelle Lösung für einen Paketfehler, der mich fast dazu gebracht hätte, ihn zu verwerfen

Als ich Parcel zum ersten Mal getestet habe, fühlte es sich instabil an. Es würde nicht herunterfahren, würde von Zeit zu Zeit einfach meinen package.json überschreiben , und insgesamt überhaupt nicht sehr gut funktionieren.

Ich war fast bereit aufzugeben, als ich dieses Problem auf GitHub fand. Es stellte sich heraus, dass ich einen package-lock.json hatte irgendwo weiter oben im Dateibaum (wahrscheinlich ein Backup, das ich zuvor erstellt hatte). Dies führte dazu, dass Parcel alle möglichen seltsamen Verhaltensweisen zeigte (nicht nur das in der Ausgabe beschriebene). Wenn Sie sich also entscheiden, diesen Ansatz auszuprobieren und das Gefühl haben, dass Parcel auf seltsame Weise „ausrastet“, könnte es sich lohnen, nach package.json zu suchen , packaage-lock.json oder ähnliche Dateien weiter oben im Dateibaum.

Das Problem lässt sich also insgesamt leicht beheben. Aber das hätte mich fast (was schade gewesen wäre!) dazu gebracht, mich von Parcel abzuwenden, also wollte ich diesen Hinweis hier einfügen.

Noch mehr Details

Außerdem habe ich alles, was ich über den Prozess gelernt habe / wie das Repo aufgebaut ist, in einer Notion Page dokumentiert. Wenn Sie sich entscheiden, diese Monorepo-Konfiguration auszuprobieren, könnte dies für Sie nützlich sein, da sie alle Befehle enthält, die Sie kennen müssen, Links zu verschiedenen wichtigen Ressourcen und so weiter.

Autor

Pablo Klaschka (sie/sie)

Werkstudent, Creative Cloud Platform und Ecosystem Team @ Adobe; Ich mache viele Dinge. Darunter die Entwicklung von Websites und Plugins für Adobe-Produkte, hauptsächlich Adobe XD. Viva la Open-Source!