npm 11.18.0, veröffentlicht am 29. Juni 2026, ist die Release, die die Arbeit am isolierten Install abschließt, die das npm-CLI seit dreieinhalb Jahren verfolgt. Die Schlagzeile ist PR #9677 (Backport von #9674), die --install-strategy=linked von experimentell auf stabil hebt. Der Modus wurde in PR #6078 am 25. Januar 2023 zur RFC npm/rfcs#0042, der Isolated-Mode-RFC aus dem Contributor Summit 2022, hinzugefügt. Die Beförderung nimmt die implizite Warnung „dies könnte Ihr node_modules fressen“, die die Doku seit 2023 trägt, und ist das Schlusskapitel der längsten Anstrengung des npm-Teams im Bereich Installationsstrategien.
Die Release ist die zweite Feature-Release der v11-Linie in diesem Monat und erscheint zusammen mit der npm-v12-Prerelease, die das Team am selben Tag getaggt hat. Die v11-Linie ist die stabile Linie; die v12-Prerelease ist der Ort, an dem die block-unreviewed-install-scripts-by-default-Änderung und die linked-Mode-Beförderung gegen die kommende Major neu angewendet werden.
Was --install-strategy=linked konkret ändert
Die Standard-Installationsstrategie von npm ist hoisted. Jede transitive Abhängigkeit wird in das oberste node_modules dupliziert, sodass jedes Paket jede transitive Abhängigkeit, die zufällig gehoistet wurde, requiren kann, selbst wenn nichts in seinem package.json sie deklariert. Das ist die Grundursache von Phantom-Abhängigkeiten: Code, der eine Bibliothek importiert, die nie zu seinen eigenen dependencies hinzugefügt wurde, und der Bug taucht erst auf, wenn ein Kollege mit einem sauberen node_modules installiert und das Hoisting anders ausfällt.
--install-strategy=linked (auch Isolated-Modus genannt) installiert stattdessen jedes Paket in node_modules/.store/<name>@<version>/node_modules/<dep> und verlinkt die deklarierten Abhängigkeiten jedes Pakets symbolisch in dessen eigenes node_modules/<dep>. Das Ergebnis ist, dass ein Paket nur das importen kann, was es deklariert hat. Importiert es eine nicht deklarierte Bibliothek, schlägt der Import sofort fehl, statt durch Zufall zu funktionieren und kaputt in Produktion zu landen.
Die npm-Install-Doku beschreibt die vier Strategien so:
hoisted(Standard): installiert ohne Duplikate auf der obersten Ebene, dupliziert bei Bedarf innerhalb der Verzeichnisstruktur.nested(ehemals--legacy-bundling): installiert direkt, ohne Hoisting.shallow(ehemals--global-style): installiert nur direkte Abhängigkeiten auf der obersten Ebene.linked: installiert innode_modules/.store, verlinkt direkt, kein Hoisting.
Die Release-Notes zu 11.18 fügen die Doku-Empfehlung hinzu, die aus der Strategie eine echte Empfehlung statt eines versteckten CLI-Flags macht. Die Doku-Seite sagt nun: „Wir empfehlen Paketautoren, --install-strategy=linked während der Entwicklung zu verwenden, um nicht deklarierte (phantom) Abhängigkeiten vor dem Veröffentlichen abzufangen: Das isolierte Layout legt nur die deklarierten Abhängigkeiten eines Pakets offen, sodass ein import eines Pakets, das nie zu package.json hinzugefügt wurde, fehlschlagen kann, statt sich durch Zufall aufzulösen und kaputt zu verschiffen. Siehe Catching undeclared (phantom) dependencies.“
Dieser Satz wurde durch PR #9690 hinzugefügt, die Doku-Änderung, die parallel zur Beförderung zurückportiert wird.
Warum dreieinhalb Jahre experimentell
Drei Gründe. Erstens brachte das experimentelle-Flag scharfe Kanten mit sich. Das Tracking-Issue #9608 des Teams ([Tracking] install-strategy=linked (isolated mode) bugs) listet 19 einzelne Bugs über den Install-Pfad, den Audit-Pfad, den npm exec-Pfad und den npm ls-Pfad, die die 11.18-Release schließt. Die vier, die das Team als die schlimmsten markiert hat, sind Audit liefert Null Ergebnisse bei einer echten Schwachstelle (#9609), npm ls meldet fälschlich UNMET DEPENDENCY (#9095), napi-postinstall kann eine installierte optionale Native-Bindung nicht auflösen (#9620) und der .store-Layout-Mismatch mit dem versteckten Lockfile (#9612). Die 11.18-Fixes für jeden davon sind die PRs #9638, die Folge von #9095 unter der Logik von #9638, der Fix von #9620 unter #9665 und #9642 entsprechend.
Zweitens brauchte die Strategie eine Audit-Story. PR #9625 auditiert den nicht-isolierten Baum unter der linked-Strategie, sodass npm audit sowohl die linked-Sicht als auch den zugrundeliegenden Store durchläuft und Schwachstellen korrekt meldet. PR #9638 macht den Audit-Bericht deterministisch, indem sie die verlorenen via-Links wieder anhängt, sodass zwei aufeinanderfolgende npm audit-Läufe auf einem unveränderten Lockfile byteidentische Ausgaben erzeugen, worauf die CI-Infrastruktur des Teams für diff-basierte Regressionstests angewiesen ist.
Drittens die Workspace-Story. PR #9666 und #9665 bringen der linked-Strategie bei, transitive optionale Abhängigkeiten zu laden und dev/prod-Flags innerhalb von Workspaces korrekt anzuwenden; #9648 sorgt dafür, dass npm exec Workspace-lokale Bins auflöst; #9669 macht nicht deklarierte Workspaces unter der linked-Strategie sichtbar, sodass ein fehlender workspaces-Eintrag nicht stillschweigend eine Teilinstallation erzeugt. Vor 11.18 funktionierte die linked-Strategie für Single-Package-Repos, stolperte aber über Workspace-Setups; nach 11.18 ist sie der empfohlene Alltagstreiber für Workspaces.
Der neue npm install-scripts-Namensraum
PR #9635 (Backport von #9629) führt einen npm install-scripts-Namensraumbefehl ein, der drei Unterbefehle besitzt: npm install-scripts approve, npm install-scripts deny und npm install-scripts ls. Die bisherigen Befehle npm approve-scripts und npm deny-scripts bleiben für eine Release als Alias erhalten und werden dann entfernt. Der Namensraum lenkt die Install-, Rebuild- und strict-allow-scripts-Hinweise auf die neuen Befehle um, sodass ein Entwickler, der npm install ausführt und auf die neue Zeile „npm install blocked N scripts“ stößt, in dieselbe Befehlsfamilie verwiesen wird.
Der Grund für den Namensraum ist, dass approve-scripts ein Spezialfall-Befehl war, der neben dem Rest der npm-Befehlsoberfläche saß; install-scripts rückt ihn in dieselbe Familie wie install, install-test und den Rest. Das gibt dem Team auch Platz, Unterbefehle hinzuzufügen: npm install-scripts ls ist neu in 11.18 und gibt die aktuelle Allow-/Deny-Liste mit Paketnamen und Pfaden aus.
Die Release fügt zudem PR #9662 (install-scripts: prune unused allowScripts entries) hinzu, die die Allow-Liste bei jeder Installation durchgeht und Einträge entfernt, deren Paket nicht mehr in dependencies steht. Das schließt einen langjährigen Schönheitsfehler, bei dem die Allow-Liste monoton wuchs: Wenn Sie esbuild für package-a genehmigten und dann esbuild aus den Deps von package-a entfernten und zu package-b hinzufügten, behielt die Allow-Liste den ursprünglichen Eintrag. Nach 11.18 entfernt der Sweep ihn im Rahmen von npm install, und der Benutzer wird aufgefordert, unter package-b erneut zu genehmigen.
Die min-release-age-Audit-Fix-Warnung
PR #9564 (Backport von #9544) bringt npm audit fix bei, zu erkennen, wenn der ansonsten anwendbare Fix durch die in .npmrc gesetzte minimumReleaseAge-Policy blockiert wird. Dieselbe Policy wird von pnpm ausgeliefert, und der Astro-6.4.4-Update-Flow zeigt sie für @astrojs/upgrade an. Die npm-Version warnt explizit, wenn die Policy einen Audit-Fix blockiert, statt stillschweigend nichts zu tun:
npm audit fix
# 3 vulnerabilities (1 low, 1 moderate, 1 high)
#
# Could not auto-fix 1 vulnerability:
# package: glob-parent <6.0.0 (transitive via some-tool)
# blocked by minimumReleaseAge=4320 (cool-down window)
# set `minimum-release-age=0` or wait for the cool-down to expire.
Der Text hat dieselbe Form wie die pnpm-Warnung ERR_PNPM_MIN_RELEASE_AGE. Die PR-Beschreibung des npm-Teams sagt, sie „wollen, dass Benutzer den Unterschied zwischen ‚kein Fix verfügbar‘ und ‚Fix existiert, wird aber durch die Policy zurückgehalten‘ erkennen können“, was die vorherige npm audit fix-Ausgabe nicht erlaubte.
SBOM und weitere Fixes
Drei npm sbom-Fixes werden in 11.18 ausgeliefert. PR #9693 prozent-encodiert den vcs_url-Qualifier in den generierten Purls, was einen langjährigen Bug im CP-Tooling schließt, bei dem eine URL git+https://github.com/foo bar/bar (mit Leerzeichen) verbatim ausgegeben und von nachgelagerten Parsern abgelehnt wurde. #9631 auditiert den nicht-isolierten Baum unter der linked-Strategie, sodass SBOM- und npm audit-Berichte beide den vollständigen Dependency-Satz erfassen. #9641 validiert peerOptional-Konflikte in No-Save-Mutationen, was bedeutet, dass npm install some-pkg --no-save die Installation verweigert, wenn sie einen peerOptional-Konflikt erzeugen würde.
Die Release fixt zudem PR #9602 (inerte optionale Deps in strict-allow-scripts nicht melden), #9607 (Deps ohne aufgelöste URL namentlich genehmigen) und #9663 (allowScripts-Enforcement-Lücken schließen). Zusammengenommen bedeutet das, dass der in npm 11.5 eingeführte strict-allow-scripts-Modus nun korrekt zwischen Paketen unterscheidet, die Scripts brauchen (der Install-Hook ist aktiv, der Audit-Hook fängt sie), und solchen, die keine brauchen (der Install-Hook ist deaktiviert, weil es kein Install-Script gibt).
Warum das wichtig ist
--install-strategy=linked ist die Antwort von npm auf die Frage, die pnpm seit 2017 beantwortet: Wie verhindert man, dass ein Paket eine transitive Abhängigkeit importiert, die es nie deklariert hat? pnpm hat das experimentelle-Flag nie getragen; yarn berry liefert PnP als Default; npm ist das dritte der drei, das den Status „stabil und für den täglichen Gebrauch empfohlen“ erreicht. Die Beförderung ist der Moment, in dem das Installationsmodell, das alle anderen als Default behandeln, endlich ein von npm empfohlener Default-Pfad wird.
Für Paketautoren ist die praktische Änderung klein und konkret. Fügen Sie dies zu .npmrc hinzu:
install-strategy=linked
Führen Sie dann npm install in CI als Teil von npm publish aus. Wenn der Build nun fehlschlägt, weil eine Testdatei eine nicht deklarierte Bibliothek importiert, haben Sie einen echten Bug zu beheben, bevor Sie veröffentlichen, und keine Phantom-Abhängigkeit, die bei einer sauberen Installation eines Kollegen explodiert.
Die gleiche Änderung gilt für Monorepo-Besitzer. Die 11.18-Fixes für npm exec (#9648), npm ls (#9664), Workspaces (#9666) und das .store-Aufräumen beim Strategiewechsel (#9649) schließen die Lücken, die --install-strategy=linked zuvor für Workspaces unbenutzbar machten. Ein Monorepo kann install-strategy=linked in .npmrc an der Wurzel ausliefern und sich darauf verlassen, dass es in Workspaces propagiert.
Die Release ist zudem die erste seit dem Supply-Chain-Artikel vom 6. Juni, die die strict-allow-scripts-Audit-Lücken aus jenem Artikel schließt. Die Flags --install-blocked-scripts und strict-allow-scripts aus npm 11.5 sind nun durchgängig nutzbar, und der neue npm install-scripts-Namensraum ist der Ort, an dem die Genehmigungen leben.
