pnpm 11.8.0 erschien am 18. Juni 2026, drei Tage nach 11.7.0, dem Release, das --frozen-store, die Auflösungsdelegation an pacquet und einen Path-Traversal-Fix im Lockfile hinzufügte. Wo 11.7 sich um reproduzierbare und schreibgeschützte Installationen drehte, zielt 11.8 auf Observability und Supply-Chain-Reporting ab: ein Dry-Run-Modus, der npm endlich entspricht, ein Node.js-Package-Map-Format, das die Auflösungsexperimente des Runtimes speist, und zwei CycloneDX-SBOM-Verbesserungen, die pnpm sbom für echte Compliance-Workflows brauchbar machen. Dazu kommt ein zweiter Path-Traversal-Advisory, diesmal in configDependencies, und ein macOS-Gatekeeper-Fix, der Nutzer nativer Module schon länger nervte.
pnpm install --dry-run: die Funktion, die npm hatte und pnpm nicht
Der wichtigste Neuzugang ist --dry-run für pnpm install. Es führt eine vollständige Abhängigkeitsauflösung gegen die aktuellen Manifeste durch und gibt aus, was eine Installation hinzufügen, entfernen oder ändern würde, schreibt dann aber nichts: kein pnpm-lock.yaml, kein node_modules, keine Store-Mutation. Es beendet sich immer mit Code 0, was der Semantik von npm install --dry-run entspricht und Issue #7340 schließt, das seit 2022 offen war.
Der praktische Anwendungsfall ist CI und Code-Review: ein PR, der eine Abhängigkeit anhebt oder einen Katalog-Eintrag wechselt, kann pnpm install --dry-run ausführen, um den vollständigen transitiven Diff offenzulegen, einschließlich Peer-Warnungen und Build-Script-Freigaben, ohne das Arbeitsverzeichnis anzutasten. Da pnpm die Auflösung ohnehin schnell durchführt, kostet es einen Auflösungsdurchlauf ohne Dateisystem-Schreibzugriff. Der Exit-Code ist bewusst immer 0, damit das Flag innerhalb eines bestehenden Installationsschritts liegen kann, ohne eine Pipeline bei einem harmlosen Diff auf Rot zu schalten.
Node.js-Package-Maps unter node_modules/.package-map.json
11.8 kann nun eine node_modules/.package-map.json während isolierter (Standard) und gehobener Installationen erzeugen. Zwei Einstellungen steuern das Verhalten:
node-experimental-package-map: Wenn aktiviert, injiziert pnpm die erzeugte Map in die Node.js-Skriptumgebungen, die es verwaltet, sodass der Runtime eine vorberechnete Paket-Layout-Beschreibung konsultieren kann, stattnode_modulesbeim Start zu durchlaufen.node-package-map-type: wählt zwischen einerstandard- und einerloose-Map und tauscht dabei Strenge gegen Kompatibilität ein.
Das ist frühe Infrastruktur für die Package-Auflösungsreform von Node, bei der eine deklarative Map-Datei die implizite, dateisystemgetriebene Auflösung ersetzen könnte, die jeder Paketmanager derzeit umgehen muss. Dass pnpm die Map erzeugt, bedeutet, dass Projekte, die sie aktivieren, eine konsistente Layout-Beschreibung erhalten, unabhängig davon, ob sie den isolierten oder den gehobenen Linker verwenden. Der Name der Einstellung (node-experimental-package-map) signalisiert, dass das Format noch nicht stabil ist.
SBOM: devDependencies-Scope und Erzeugung pro Paket
Die beiden SBOM-Änderungen in 11.8 zielen auf die Lücke zwischen einem Abhängigkeitsbaum und dem, was ein CycloneDX-Konsument tatsächlich erschließen kann.
Erstens markiert pnpm sbom nun Komponenten, die nur über devDependencies erreichbar sind, mit dem CycloneDX-Scope scope: "excluded" und der Eigenschaft cdx:npm:package:development. Der Scope excluded ist die CycloneDX-Art, „Komponentennutzung für Test- und andere Non-Runtime-Zwecke“ zu dokumentieren, was genau einer devDependency entspricht. Die Eigenschaft spiegelt den Marker, den @cyclonedx/cyclonedx-npm ausgibt, sodass sowohl moderne (scope-basierte) als auch bestehende (eigenschaftsbasierte) Konsumenten ihn erfassen. Komponenten, die zur Laufzeit erreichbar sind, einschließlich installierter optionalDependencies, lassen den scope weg und standardisieren auf required.
Zweitens kommt die SBOM-Erzeugung pro Paket über zwei Flags:
--out out/%s.cdx.jsonschreibt ein CycloneDX-Dokument pro Workspace-Paket in einzelne Dateien.--splitgibt NDJSON auf stdout aus, ein Paket pro Zeile.
Wenn --filter ein einzelnes Paket auswählt, verwendet die SBOM-Wurzelkomponente nun die Metadaten dieses Pakets. Workspace-Interabhängigkeiten, die über das workspace:-Protokoll deklariert sind, sowie deren transitive Abhängigkeiten werden einbezogen, sodass eine pro-Paket-SBOM in sich geschlossen ist. Autor, Repository und Lizenz fallen auf das Wurzel-Manifest zurück, wenn das Paket sie nicht definiert. Für ein Monorepo, das pro veröffentlichter Bibliothek eine SBOM ausliefern muss, ist das der Unterschied zwischen dem Nachbearbeiten eines riesigen Dokuments und dem Erhalt pro-Paket-Artefakte direkt vom Installationstool.
Path-Traversal bei configDependencies (GHSA-qrv3-253h-g69c)
11.8 schließt einen zweiten Path-Traversal-Advisory, unterschieden vom Lockfile-Alias-Fix in 11.7 und der esbuild-0.28.1-Windows-Traversal, die in einem anderen Werkzeug aufgetaucht war. Vor 11.8 konnte ein committetes Lockfile, dessen configDependencies einen traversal-förmigen Namen (etwa ../../PWNED) oder eine Version (etwa ../../../PWNED) enthielten, bewirken, dass pnpm install Symlinks oder Paketdateien außerhalb von node_modules/.pnpm-config und dem Store anlegt.
Der Fix validiert die Namen und Versionen der configDependencies, bevor sie für Pfadkonstruktionen verwendet werden. Namen müssen nun gültige npm-Paketnamen und Versionen exakte Semver-Strings sein. Dieselbe Validierung läuft auf optionale Subabhängigkeiten von configDependencies und auf das Legacy-Workspace-Manifest-Format, bevor ein Lockfile geschrieben wird. Wie das Lockfile-Gate in 11.7 ist das Defense in Depth: ein Projekt, das seiner Lockfile-Quelle bereits vertraut, profitiert dennoch, weil die Prüfung vor teilweiser Korruption und vor Bugs im Lockfile-Generator selbst schützt. Siehe GHSA-qrv3-253h-g69c.
macOS Gatekeeper blockiert native Binaries nicht mehr
Ein leiserer, aber weit verbreitet spürbarer Fix: Wenn pnpm Dateien aus seinem inhaltsadressierbaren Store nach node_modules importiert, bewahrt macOS erweiterte Attribute, darunter com.apple.quarantine. War dieses xattr auf einem Store-Blob vorhanden (es wurde beispielsweise zuerst unter einer Gatekeeper-aktivierten App wie einem Git-Client geschrieben), propagierte es nach node_modules, und Gatekeeper blockierte das Laden des nativen Binaries, obwohl pnpm die Dateiintegrität bereits gegen das Lockfile geprüft hatte.
Nach dem Import eines Pakets entfernt 11.8 nun com.apple.quarantine von nativen Binaries (.node, .dylib, .so), entsprechend dem Verhalten von Homebrew, das Quarantäne von geprüften Downloads entfernt. Die Bereinigung ist nur für macOS, läuft in einem gebündelten xattr-Aufruf pro Paket, ist auf native Binaries beschränkt, sodass andere Dateien unangetastet bleiben, und ist nicht fatal. Er behebt #11056.
Weitere erwähnenswerte Fixes
pnpm run --no-bail beendet sich nun mit einem von Null verschiedenen Code, wenn ein ausgeführtes Skript fehlschlägt, während es dennoch alle passenden Skripte bis zum Ende ausführt. Das schließt Issue #8013: nicht-rekursive --no-bail-Läufe beendeten sich bisher immer mit 0 selbst bei Fehlschlag, was inkonsistent mit rekursiven Läufen war, die bereits am Ende fehlschlugen.
pnpm view ohne Paketnamen sucht nun aufwärts nach dem nächsten Projekt-Manifest (package.json, package.yaml oder package.json5) und verwendet dessen name-Feld und ersetzt die find-up-Abhängigkeit durch das schnellere Modul empathic. Mehrere Lockfile-Korrektheits-Bugs kommen ebenfalls dazu: inkrementelle Installationen behalten keine duplizierten transitiven Abhängigkeiten mehr, die eine frische Installation nicht erzeugt hätte (#5108), optimisticRepeatInstall meldet nicht mehr „Already up to date“, wenn nur das Lockfile geändert wurde (#12100), und Katalog-Overrides, die über einen Katalog aufgelöst werden, bleiben während pnpm update mit dem Katalog synchron. pnpm version --recursive respektiert nun den Workspace-Filter statt jedes Paket anzuheben (#11348). Die Reporter-Ausgabe für pnpm store und pnpm config geht nun auf stderr, sodass Skripte wie PNPM_STORE=$(pnpm store path) keine Warnungen mehr im Ergebnis erfassen.
Upgrade
pnpm 11.8.0 benötigt Node.js 22.13 oder neuer, dieselbe Basis wie 11.7. Das Lockfile-Format ist unverändert, sodass ein npm install -g pnpm@latest (oder corepack prepare pnpm@latest --activate) gefolgt von einem pnpm install den vollständigen Upgrade-Pfad darstellt. Die neuen Flags sind alle opt-in, und die configDependencies-Validierung lehnt nur Eingaben ab, die nie gültige Paketnamen waren.
