Warum pnpm schneller installiert als npm: Speicher, Verknüpfungen und Strict node_modules

Nach dem Umzug eines Repositoriums von npm auf pnpm sinkt die Installationsdauer oft stark. Dieser Unterschied ist keine Einbildung. pnpm wurde unter Berücksichtigung der Leistungs- und Speicherprobleme bei herkömmlichen npm-Installationen entwickelt, und die beiden Tools speichern Pakete so unterschiedlich, dass der Geschwindigkeitsunterschied auf einer architektonischen Veränderung beruht und kein kleiner Anpassungsfehler ist.

In den folgenden Abschnitten werden die Gründe erläutert, warum pnpm in der Regel vorteilhaft ist – insbesondere wenn Anwendungen und Monorepos größer werden.

1. Ein inhaltsspezifischer Speicher anstelle doppelter Dateien

Der größte Vorteil ergibt sich daraus, wie Pakete auf der Festplatte abgelegt werden. Bei npm erhält jedes Projekt seinen eigenen physischen Baum aller Abhängigkeiten unter node_modules. Zehn Anwendungen, die alle lodash benötigen, speichern daher zehn separate Kopien dieser Version auf der Festplatte.

pnpm verwaltet für den Rechner einen globalen, adressierbaren Speicher. Jede Version nimmt dort einen einzigen Platz ein; ein Projekt, das sie benötigt, erhält von diesem Speicher Hardlinks (oder Copy-on-Write-Referenzen) in seinen lokalen node_modules. Dazu gehören folgende Vorteile:

• Ausgelassene Neuherunterladevorgänge, wenn der Speicher die Version bereits enthält
• Ausgelassene Neuüberwrites von Bytes, die bereits auf der Festplatte vorhanden sind
• Weit geringerer Speicherverbrauch, wenn viele Projekte Bibliotheken teilen

Da die Installationsarbeit hauptsächlich durch Festplatten-Eingabe/Ausgabe bestimmt wird, verschwindet der größte Teil der Verzögerung durch das Vermeiden wiederholter Schreibvorgänge.

2. Hardlinks und Symbollinks anstelle von Kopieren

Npm kopiert die Paketdateien über den Installationsweg in node_modules. Das Kopieren von Tausenden von Dateien in einem tiefen Verzeichnisbaum ist aufwändig.

pnpm bevorzugt Hartverknüpfungen aus dem globalen Speicher in das Projekt sowie Symbole, die die verschachtelte Struktur so anpassen, dass sie dem Abhängigkeitsgraphen entspricht. Im Vergleich zu einer Kopie sind Verknüpfungen im Grunde kostenlos: Das Betriebssystem speichert einfach einen weiteren Zeiger auf dieselben Blöcke anstelle dessen, sie zu duplizieren.

3. Effizientes Caching zwischen Projekten

npm kauft zwar auch Downloads in den Cache, kopiert diese aber dennoch aus diesem Cache in jedes Projekt. Bei pnpms Speichermodell ist es, sobald eine Version irgendwo auf dem Rechner vorhanden ist, nahezu sofort möglich, sie in ein völlig neues Projekt zu übernehmen – ohne erneuten Download und mit nur geringer zusätzlicher Verarbeitung.

Dieses Verhalten fällt besonders ins Auge, wenn:

• zwischen Branchen gewechselt wird, die unterschiedliche Abhängigkeitsmengen verwenden
• mehrere Repositorien gepflegt werden, die gemeinsame Bibliotheken teilen
• CI-Aufgaben ausgeführt werden, die einen gemeinsamen Speicher über verschiedene Builds hinweg wiederherstellen

4. Eine nicht-flache node_modules-Struktur, die zusätzliche Auflösungsarbeiten vermeidet

Ältere Versionen von npm „hoisten“ die node_modules-Struktur, um Duplikate zu reduzieren, doch diese Strategie hat ihren eigenen Aufwand: eine aufwändige Auflösung, um festzulegen, wo jedes Paket ohne Konflikte platziert werden soll.

pnpm behält eine streng strukturierte, mit Symbolverweisen versehene node_modules-Struktur bei, sodass ein Paket nur die von ihm deklarierten Abhängigkeiten sieht (keine versehentlichen „Phantom-Imports“). Eine sicherere Auflösung ist dabei nicht der einzige Vorteil – es entfällt außerdem die teure Planung durch npm, wodurch während der Installationen weniger CPU-Ressourcen verbraucht werden.

5. Parallelisierte Operationen

pnpm plant die Schritte Auflösen, Herunterladen und Verknüpfen so oft wie möglich gleichzeitig ein – aggressiver als der übliche Ansatz von npm. In Kombination mit I/O-Operationen, bei denen statt Kopieren Verknüpfungen verwendet werden, sinkt die Gesamtlaufzeit noch weiter, insbesondere bei Projekten mit sehr großen Abhängigkeitsgraphen.

6. Der Einfluss in der Praxis wächst mit der Projektgröße

In einer einfachen App mit nur wenigen Paketen mag der Unterschied gering erscheinen. Der Vorteil nimmt zu, wenn:

• Monorepos verwendet werden, bei denen viele Pakete dieselben Bibliotheken wiederverwenden
• Teams mehrere Produkte mit gemeinsamen Abhängigkeiten verwalten
• CI/CD-Pipelines bei jeder Build-Ausführung wiederholt installiert werden
• große Abhängigkeitsbäume typisch für moderne Frontend-Stacks vorliegen

In solchen Umgebungen können Installationsvorgänge, die früher unter npm Minuten in Anspruch nahmen, auf Sekunden verkürzt werden.

7. Der Speicherplatzersparnis ist ein Nebeneffekt, nicht nur ein Bonus

Schnelligkeit steht im Vordergrund, doch dasselbe Design löst auch das Problem der Speicherung. Da Pakete nicht pro Projekt geklont werden, können Gruppen oft Gigabyte freisetzen. Auf langsameren Festplatten führt auch die geringere Menge an zu verarbeitenden Daten als Nebeneffekt zu einer höheren Durchsatzrate.

Eine kurze Analogie

Bilden Sie sich npm als eine Bibliothek vor, die für jeden Ausleiher denselben Titel kopiert. pnpm hingegen ist eine Bibliothek, in der alle denselben Regalbereich teilen und jeder Leser einen Lesezeichen zur gemeinsamen Kopie erhält. Das Fotokopieren kostet Zeit und Papier; auf ein bereits vorhandenes Exemplar zu verweisen ist fast kostenlos.

Fazit

Der Vorteil von pnpm gegenüber npm ist keine rein kosmetische Eigenschaft. Es überdenkt die Speicherung und Vernetzung: Duplizierter Downloads werden vermieden, Links statt Kopien bevorzugt und unnötige Aufwände weggelassen. Die Installation – oft der langsamste Teil von Frontend-Arbeitsabläufen – wird dadurch zu einem schnelleren und effizienteren Schritt.

Für Teams mit mehreren Projekten oder einem Monorepo gehört die Einführung von pnpm zu den einfachsten Verbesserungen, die sowohl die Installationszeit als auch den Datenträckverbrauch verringern können.