pnpm 12 verlagert die Paketinstallation nach Rust
Der JavaScript-Paketmanager pnpm erhält mit Version 12 einen weitgehend neu entwickelten Kern in Rust. Das native Programm übernimmt rechenintensive Aufgaben, die bisher über Node.js liefen. Dazu gehören das Auflösen von Abhängigkeiten, das Entpacken von Archiven und das Verknüpfen von Paketen im Verzeichnis node_modules.
Nach Angaben des Projekts besteht pnpm 12 zu 65,9 % aus Rust und zu 33,5 % aus TypeScript. Die Arbeiten am neuen Kern begannen im April. Rust eignet sich für diesen Bereich, weil die Sprache parallele Verarbeitung und direkten Zugriff auf das Dateisystem ermöglicht, ohne eine automatische Speicherbereinigung wie bei JavaScript.
Der Umbau reiht sich in einen breiteren Trend ein. Immer mehr Werkzeuge aus dem Web-Ökosystem ersetzen besonders rechenintensive Komponenten durch Rust. Auch Canonical setzt bei der Modernisierung bestehender Software auf Rust, dort allerdings für die Übersetzung großer C-Codebestände.
Installationszeit sinkt im Benchmark deutlich
In einem Projektbenchmark installierte pnpm 12 ein zuvor nicht zwischengespeichertes Beispielpaket in 5,19 Sekunden. pnpm 11 benötigte dafür 8,22 Sekunden, npm kam auf 47,7 Sekunden. Mit dem ebenfalls in Rust entwickelten Registry-Server pnpr sank die gemessene Zeit auf 3,37 Sekunden.
| Konfiguration | Installationszeit | Abstand zu pnpm 11 |
|---|---|---|
| npm | 47,7 Sekunden | 480 % langsamer |
| pnpm 11 | 8,22 Sekunden | Referenz |
| pnpm 12 | 5,19 Sekunden | 37 % schneller |
| pnpm 12 mit pnpr | 3,37 Sekunden | 59 % schneller |
Das Projekt spricht je nach Szenario von bis zu 90 % kürzeren Installationszeiten. Solche Werte lassen sich nicht pauschal auf jede Entwicklungsumgebung übertragen. Netzwerkverbindung, Paketcache, Zahl der Abhängigkeiten und Speichersystem beeinflussen das Ergebnis erheblich.
Kompatibilität zu pnpm 11 soll erhalten bleiben
Der Wechsel auf Rust soll keine Migration von Projektdateien erfordern. Befehle, Optionen, Einstellungen und das Lockfile-Format von pnpm 11 bleiben nach Angaben des leitenden Entwicklers bestehen. Die Dokumentation gilt ebenfalls für beide Hauptversionen.
Sinngemäß übersetzt: Ein Upgrade soll sich nicht wie eine Migration anfühlen. Befehle, Einstellungen und Lockfiles aus pnpm 11 können weiterverwendet werden.
Zum Veröffentlichungszeitpunkt verweist die zentrale Projektseite teilweise noch auf pnpm 11.25. Wer Version 12 gezielt testen möchte, muss deshalb den entsprechenden Zweig mit pnpm self-update next-12 auswählen. Für produktive Build-Pipelines empfiehlt sich zunächst ein Test mit bestehenden Lockfiles und reproduzierbaren Builds.
Warum pnpm besonders bei Monorepos relevant ist
pnpm unterscheidet sich von npm durch einen inhaltsadressierten Paketspeicher. Identische Paketversionen werden nur einmal gespeichert und anschließend in mehrere Projekte eingebunden. Das reduziert den Speicherbedarf, besonders wenn zahlreiche Anwendungen dieselben Bibliotheken verwenden.
Dieser Ansatz ist für Monorepos interessant, in denen mehrere Anwendungen und Bibliotheken gemeinsam verwaltet werden. In der State of JavaScript Survey 2025 gaben 3.840 von 10.251 Befragten an, pnpm für solche Strukturen einzusetzen. Das entspricht rund 38 %.
Für Unternehmen wirkt sich eine schnellere Installation vor allem in Continuous-Integration-Systemen aus. Wenn Abhängigkeiten bei jedem Build neu aufgelöst und installiert werden, können wenige eingesparte Sekunden pro Lauf über viele Teams hinweg relevante Rechenkosten reduzieren. Lokal verkürzen sich zugleich Wartezeiten beim Wechsel zwischen Branches oder beim Neuaufsetzen einer Entwicklungsumgebung.
Mehr Geschwindigkeit beseitigt keine Lieferkettenrisiken
Der Rust-Kern verändert nicht die Herkunft der Pakete. pnpm greift weiterhin auf das npm-Repository und dessen Abhängigkeitsnetz zurück. Manipulierte Pakete, kompromittierte Entwicklerkonten oder riskante Installationsskripte bleiben deshalb ein separates Sicherheitsproblem.
Dass auch moderne Paketökosysteme anfällig sind, zeigen unter anderem manipulierte Rust-Pakete mit integriertem Infostealer. Unternehmen sollten Paketquellen daher weiterhin prüfen, Versionen festschreiben und Build-Umgebungen isolieren. Der Wechsel des Paketmanagers ersetzt keine Kontrolle der Software-Lieferkette.
Rust statt zusätzlicher SaaS-Schicht
pnpm 12 zeigt, dass erhebliche Leistungsgewinne nicht zwingend einen neuen Cloud-Dienst oder ein weiteres Entwickler-Abo erfordern. Der Paketmanager bleibt Open Source und optimiert eine lokale Kernfunktion direkt. Das reduziert die Abhängigkeit von proprietären Build-Plattformen, sofern die eigene Infrastruktur entsprechend gepflegt wird.
Der praktische Nutzen hängt vom Umfang der JavaScript-Projekte ab. Bei kleinen Anwendungen dürfte der Unterschied kaum geschäftskritisch sein. In großen Monorepos mit vielen täglichen Builds können kürzere Installationszeiten dagegen Entwicklungszeit und Cloud-Kosten messbar senken.