Hallo zusammen! Sie haben sicher schon gesehen, die unterschiedliche Paketmanager verwenden, beispielsweise: Node.js-Projekte (der Standard) npm Garn pnpm Ich habe das selbst gesehen und mit all dem oben genannten gearbeitet, aber ich hatte immer eine Frage im Kopf – was bewegt Leute/Teams dazu, oder statt zu verwenden? Was sind die Vorteile? Gibt es irgendwelche Nachteile? yarn pnpm npm Nun... finden wir es heraus! Regeln für den Leistungsvergleich Ich habe beschlossen, , und hinsichtlich ihrer „Geschwindigkeit“ zu vergleichen … npm yarn pnpm Nachfolgend sehen Sie 3 Maßnahmen: Erstellen Sie eine Sperrdatei ohne Cache. Installieren Sie Abhängigkeiten von vorhandenen Sperrdateien ohne Cache. Installieren Sie Abhängigkeiten von vorhandenen Sperrdateien mit globalem Cache. Es gibt zwei Arten von Cache: Weltweit. Normalerweise im Home-Verzeichnis des Benutzers gespeichert (zB ). ~/.yarn/berry/cache Lokal. Wird im Projektverzeichnis gespeichert (zB ). <project-dir>/.yarn Während und meiner Erfahrung nach die häufigsten Anwendungsfälle sind, habe ich vorsichtshalber auch genommen (obwohl das ein seeehr seltener Fall ist). Nr. 2 Nr. 3 Nr. 1 Als Beispiel für Benchmarks habe ich ein Beispielprojekt von verwendet. create-react-app npm Es handelt sich um einen Standardpaketmanager für das Ökosystem – was soll man sonst noch dazu sagen? Er wird mit dem Installationspaket geliefert und ist daher grundsätzlich einsatzbereit, wenn Sie auf Ihrem Computer installieren (oder in einem beliebigen Anbieter, wenn Sie dort einrichten). Node.js- Node.js CI- Node.js Das ist meiner Meinung nach ein großes „Pro“ – Sie müssen es nicht separat installieren! Nichts Besonderes – es funktioniert einfach! Und ich habe im Laufe der Jahre keine größeren Fehler gesehen – es scheint ziemlich stabil zu sein und erledigt die Arbeit. Die Funktionen von die ich bisher verwendet habe: npm, Abhängigkeiten verwalten (installieren, entfernen, aktualisieren) Pakete veröffentlichen (privat, öffentlich) Link-Local-Pakete Arbeitsbereiche verwalten. Abhängigkeiten verwalten speichert Abhängigkeiten im Ordner Ihres Projektstamms. Ziemlich unkompliziert. npm node_modules ℹ️ speichert Informationen zu Registern für die aufgelisteten Pakete – das ist praktisch, wenn Sie Pakete aus einem einzigen Bereich haben, d. h. in verschiedenen Registern (z. B. und ): package-lock.json SEHR @example-company npm- GitHub-Pakete Sehen wir uns nun an, wie die Installationsgeschwindigkeit aussieht … Generieren Sie package-lock.json ohne Cache Es dauerte damit eine generiert und Abhängigkeiten ohne Cache installiert. 1 Minute npm package-lock.json Verwendeter Befehl: npm i Installieren Sie Abhängigkeiten aus package-lock.json ohne Cache Es dauerte damit Abhängigkeiten von ohne Cache installiert. 18 Sekunden npm package-lock.json Verwendeter Befehl: npm ci Installieren Sie Abhängigkeiten aus package-lock.json mit globalem Cache Es dauerte damit Abhängigkeiten von mit globalem Cache installiert. 8 Sekunden npm package-lock.json Verwendeter Befehl: npm ci Arbeitsbereiche verwalten Ich konnte erstellen und Abhängigkeiten für den gesamten Arbeitsbereich auf einmal und für bestimmte Projekte separat verwalten. einen Arbeitsbereich Mit anderen Worten: Es erledigt die Arbeit ohne Fehler/Probleme und die offizielle Dokumentation ist ziemlich unkompliziert. Arbeitsbereichsfunktionen, die ich bisher verwendet habe: Installieren Sie Abhängigkeiten für alle Projekte innerhalb des Arbeitsbereichs. Installieren Sie Abhängigkeiten für ein einzelnes bestimmtes Projekt. Führen Sie rekursiv ein einzelnes Skript für alle Projekte gleichzeitig aus. Garn Ehrlich gesagt habe ich einige der Funktionen noch nicht oft ausprobiert. Ich meine, ich habe sie bei der Arbeit an einigen Projekten häufig zum „Installieren von Abhängigkeiten“ verwendet, und das war’s auch schon. Yarn- wird nicht mit einem Installationsprogramm geliefert, Sie müssen es also separat installieren. Das bedeutet, dass in Ihren Pipelines ein zusätzlicher Schritt erforderlich ist – Sie müssen einrichten, bevor Sie Ihre Projektabhängigkeiten installieren. yarn Node.js- CI- yarn Abhängigkeiten verwalten bietet zwei Ansätze zum Installieren von Abhängigkeiten: Yarn „ “ (Standard) – erstellt einen Ordner und listet Pakete in den Dateien und auf. Zero Installs .yarn yarn.lock .pnp.cjs Eine normale Variante – ähnlich wie – speichert Abhängigkeiten in und listet sie in der Datei auf. npm node_modules yarn.lock ℹ️ -Lock-Dateien speichern Informationen zu Registrierungen für alle aufgelisteten Pakete, wenn Sie den alten (regulären) Installationsansatz verwenden. Yarn NUR ⚠️ Bedenken Sie, dass „ “ Pakete im lokalen Cache zu speichern scheint und Links zu Ihren Sperrdateien bereitstellt: Zero Installs Dies kann für Sie wichtig sein, wenn Sie über eine oder Pipeline verfügen, in der Sie Abhängigkeiten in einer sauberen Umgebung installieren und diese dann in eine andere verschieben möchten (Sie müssen sowohl den Ordner als auch den lokalen Cache kopieren). Docker-Datei CI- .yarn Da der Standardansatz für Yarn jetzt „ “ ist und eine bessere Leistung als der alte Ansatz bietet, werden wir Benchmarks nur mit diesem Ansatz aufzeichnen. Null Installationen Sperrdateien ohne Cache generieren Es dauerte damit eine Datei generiert und Abhängigkeiten ohne Cache installiert. 16,5 Sekunden Yarn yarn.lock Verwendeter Befehl: yarn install Installieren Sie Abhängigkeiten aus vorhandenen Sperrdateien ohne Cache Es dauerte für um Abhängigkeiten mit dem „Zero Install“-Ansatz und ohne Cache zu installieren. 11 Sekunden Yarn, Verwendeter Befehl: yarn install --frozen-lockfile Installieren Sie Abhängigkeiten aus vorhandenen Sperrdateien mit globalem Cache Es dauerte für um Abhängigkeiten mit dem „Zero Install“-Ansatz und globalem Cache zu installieren. 8 Sekunden Yarn, Verwendeter Befehl: yarn install --frozen-lockfile Arbeitsbereiche verwalten Ich konnte erstellen und Abhängigkeiten für alle Projekte gleichzeitig und für bestimmte Projekte separat verwalten. einen Arbeitsbereich Arbeitsbereichsfunktionen, die ich bisher verwendet habe: Installieren Sie Abhängigkeiten für alle Projekte innerhalb des Arbeitsbereichs. Installieren Sie Abhängigkeiten für ein einzelnes bestimmtes Projekt. Führen Sie rekursiv ein einzelnes Skript für alle Projekte gleichzeitig aus. Die Dokumentation ist in Ordnung, aber Befehlsnamen und Flags sind etwas verwirrend. Beispielsweise muss ich dies ausführen, um im ( ) und im verschachtelten Projekt auszuführen: test Stammverzeichnis . b2b yarn workspaces foreach -A --include '{.,b2b}' run test Im Vergleich mit : npm npm run test --workspace=b2b --include-workspace-root pnpm ist derzeit ein Hype – . pnpm viele Unternehmen und Open-Source-Projekte verwenden es Genau wie wird nicht mit einem Installationsprogramm geliefert, Sie müssen es also separat installieren. Das bedeutet, dass in Ihren Pipelines ein zusätzlicher Schritt erforderlich ist: Sie müssen einrichten, bevor Sie Ihre Projektabhängigkeiten installieren. Yarn pnpm Node.js- CI- pnpm Abhängigkeiten verwalten gilt als … pnpm „ “ schneller, speicherplatzsparender Paketmanager Tatsächlich stimme ich der Aussage im Hinblick auf die lokale Verwaltung von Abhängigkeiten zu. „Speicherplatzeffizienz“ Standardmäßig entfernt Duplikate gemeinsam genutzter Abhängigkeiten. erstellt symbolische Links für die Pakete, die in mehreren Abhängigkeiten verwendet werden. Wenn beispielsweise die Pakete und Paket als Abhängigkeit verwenden, speichert Paket als einzelne Kopie und erstellt symbolische Links für die Pakete und . Auf diese Weise erstellt der Paketmanager keine Hardcopys und spart Speicher auf Ihrer SSD/HDD. pnpm pnpm a b c pnpm c a b ℹ️ speichert keine Informationen zu Registrierungen für die aufgelisteten Pakete. pnpm-lock.yaml ⚠️ Denken Sie daran, dass Abhängigkeiten manchmal im globalen Cache speichert, anstatt sie als Projekt zu behalten. pnpm Generieren Sie pnpm-lock.yaml ohne Cache Es dauerte damit eine generiert und Abhängigkeiten ohne Cache installiert. 31 Sekunden pnpm pnpm-lock.yaml Verwendeter Befehl: pnpm install Installieren Sie Abhängigkeiten von pnpm-lock.yaml ohne globalen Cache Es dauerte damit Abhängigkeiten von ohne Cache installiert. 16 Sekunden pnpm pnpm-lock.yaml Verwendeter Befehl: pnpm i --frozen-lockfile Installieren Sie Abhängigkeiten aus einer vorhandenen Sperrdatei mit globalem Cache Es dauerte damit Abhängigkeiten von mit globalem Cache installiert. 5 Sekunden pnpm pnpm-lock.yaml Verwendeter Befehl: pnpm i --frozen-lockfile Arbeitsbereiche verwalten Jetzt wird es wirklich interessant … hat viele Konfigurationsoptionen, aber einige Kernfunktionen funktionieren einfach nicht! pnpm Sehen wir uns ein paar Fehler an, mit denen ich konfrontiert war: pnpm install --filter Es ist wichtig, Abhängigkeiten nur für bestimmte Projekte installieren zu können. Dies ist bei Monorepos sehr nützlich, wenn Sie Pipelines erstellen, die sich auf bestimmte Projekte innerhalb des Arbeitsbereichs beziehen. Stellen Sie sich beispielsweise vor, Sie hätten in Ihrem Arbeitsbereich: eine Web-App, Backend-Server, Testprojekt (End-to-End-Tests). Dies sind alles separate Projekte, aber sie sind Teil desselben Repos ☝️ npm- Nun möchten Sie, dass eine Pipeline nur End-to-End-Tests ausführt. Sie benötigen also nur End-to-End-Testabhängigkeiten, richtig? Nun, das werden Sie nicht tun können – zwingt Sie, Abhängigkeiten für den gesamten Arbeitsbereich zu installieren! pnpm sollte nur Abhängigkeiten für ausgewählte Projekte installieren, funktioniert aber nicht. pnpm install --filter <project-name> Es handelt sich um einen ein Jahr alten Fehler, der vor Kurzem mit einem nicht funktionierenden Fix behoben wurde. rekursive-install=false installiert standardmäßig Abhängigkeiten für den gesamten Arbeitsbereich (alle Projekte), wenn Sie ausführen pnpm pnpm install Sie können dieses Verhalten ändern, indem Sie in in Ihrem Arbeitsbereichsstamm festlegen. .npmrc recursive-install=false ABER . es führt einen weiteren Fehler ein, der schon fast 2 Jahre alt ist gemeinsam genutzter Arbeitsbereich-Sperrdatei = false speichert die Abhängigkeitsliste standardmäßig in einer einzigen Sperrdatei (wie und ). pnpm npm yarn Sie können dieses Verhalten auch ändern, wenn Sie in in Ihrem Arbeitsbereichsstamm festlegen. .npmrc shared-workspace-lockfile=false Dadurch könnten wir die Arbeitsbereichsfunktion beibehalten und das Flag verwenden, um Abhängigkeiten für ein bestimmtes Projekt zu installieren. --ignore-workspace Diese Einstellung bringt jedoch einige weitere Probleme mit sich: und werfen in meinen -Pipelines einen -Fehler aus. eslint tsc --noEmit GitHub Actions „JavaScript-Heap nicht genügend Arbeitsspeicher“ Einige der Abhängigkeiten werden im globalen Cache gespeichert und in symbolisch verknüpft. node_modules/.pnpm Ergebnisse des Leistungsvergleichs # npm Garn pnpm Generieren einer Sperrdatei 60 Sek. 16,5 Sek. 31 Sek. Installieren Sie Abhängigkeiten ohne Cache 18 Sek. 11 Sek. 8 Sek. Installieren Sie Abhängigkeiten mit globalem Cache 8 Sek. 8 Sek. 5 Sek. Laut dem obigen Benchmark ist der langsamste Paketmanager ☝️ npm Lassen Sie uns diese Ergebnisse jedenfalls interpretieren … Generieren einer Sperrdatei Dies ist ein seltener Fall. Normalerweise wird bei der Projektinitialisierung eine Sperrdatei erstellt und dann erweitert, wenn Sie Pakete installieren/aktualisieren. In Anbetracht dessen scheint es kein besonders wichtiger Faktor zu sein, auf den Sie sich bei der Auswahl eines Paketmanagers verlassen sollten. Abhängigkeiten installieren In den meisten Fällen enthalten Ihre Projekte eine bestimmte Liste von Abhängigkeiten und Sie fügen selten etwas hinzu bzw. entfernen es. Höchstwahrscheinlich werden Sie von Zeit zu Zeit Versionen Ihrer Pakete aktualisieren. Diese Änderungen sind geringfügig und Sie werden die restlichen Pakete aus dem Cache wiederverwenden. Mit anderen Worten: Der übliche Anwendungsfall ist: Neue Pakete aus der Paketregistrierung abrufen und den Rest aus dem Cache holen. (5–8 Sek.) ist fast doppelt so schnell wie (8–18 Sek.) mit (8–11 Sek.) in der Mitte. pnpm npm yarn Abschluss Fakten ist tatsächlich Paketmanager – das wird in der aktuellen Rezension ganz klar! pnpm ein „schneller und festplatteneffizienter“ Arbeitsbereichsfunktion ist fehlerhaft und einige der Fehler sind seit Jahren nicht behoben. Die PNPPM- sowohl als auch erfordern eine zusätzliche Einrichtung in CI-Pipelines, während nicht der Fall ist. pnpm yarn dies bei npm weder noch speichern Paketregistrierungsinformationen in ihren Sperrdateien, hingegen schon. pnpm yarn npm Gedanken des Autors Ich denke, die beste Arbeit leistet, wenn Ihre Anforderung an den Paketmanager so einfach ist wie „nur Abhängigkeiten installieren“. dass pnpm Obwohl nicht mit einem vorinstallierten Installationsprogramm ausgeliefert wird, lässt es sich mit oder problemlos in CI-Pipelines einrichten. pnpm Node.js- Corepack einer vorhandenen Aktion Ich bevorzuge , weil: npm es ist stabil (vor allem Arbeitsbereiche), kommt mit und erfordert kein zusätzliches Setup in der CI-Pipeline, Node.js speichert Paketregistrierungen in sodass Sie Abhängigkeiten mit einem einzigen Umfang aus verschiedenen Registrierungen installieren können. package-lock.json Diese Vorteile überwiegen die Sekunden an Geschwindigkeit und Speicherplatz, die ich mit oder sparen würde. yarn pnpm Nach welchen Kriterien wählen Sie einen Paketmanager aus? Seien Sie nicht schüchtern und teilen Sie mir Ihre Meinung im Kommentarbereich unten mit! 👇😊
