---
title: "npm 11.18 befördert die `linked`-Installationsstrategie zu stabil, führt den `npm install-scripts`-Namensraum ein und warnt, wenn `min-release-age` einen Audit-Fix blockiert"
description: "npm 11.18.0 (29. Juni 2026) liefert drei Features und einen langen Bugfix-Backlog, die zusammen die Arbeit am `install-strategy=linked`-(isolated)-Installationsmodus abschließen, die das npm-CLI seit RFC #0042 aus dem Jahr 2022 verfolgt. Die Schlagzeile ist [PR #9677](https://github.com/npm/cli/pull/9677) (Backport von #9674), die `--install-strategy=linked` von experimentell auf stabil hebt. Der Modus installiert jedes Paket in `node_modules/.store/<name>@<version>/node_modules/<dep>` und verlinkt dessen deklarierte Abhängigkeiten in den eigenen `node_modules/<dep>`-Baum, sodass ein Paket nur Abhängigkeiten `require`n kann, die tatsächlich in seinem eigenen `package.json` stehen. Die neue Doku-Empfehlung ([PR #9690](https://github.com/npm/cli/pull/9690)) lautet, `--install-strategy=linked` in CI auszuführen, um Phantom-Abhängigkeiten vor dem Veröffentlichen abzufangen. Um die Beförderung herum liefert die Release den neuen `npm install-scripts`-Namensraum ([#9635](https://github.com/npm/cli/pull/9635), Backport von #9629) mit `approve`, `deny` und `ls`, wobei `npm approve-scripts` / `npm deny-scripts` als Alias erhalten bleiben; einen `install-scripts: prune unused allowScripts entries`-Aufräumdurchlauf ([#9662](https://github.com/npm/cli/pull/9662)); und eine neue Warnung, wenn `min-release-age` einen `npm audit fix` blockiert ([#9564](https://github.com/npm/cli/pull/9564)). Die 43-Commit-Release fixt zudem 19 Bugs der `linked`-Strategie (Audit-Determinismus #9638, verwaiste `.bin`-Shims #9643, Aufräumen veralteter `.store`-Verzeichnisse #9649, ungültiger `filterNode`-Crash #9645, peerOptional-Validierung #9641), drei `npm sbom`-Fixes und einen Prozent-Encoding-Fix für den `vcs_url`-Qualifier in generierten Purls ([#9693](https://github.com/npm/cli/pull/9693))."
date: 2026-06-30
image: "/images/heroes/2026-06-30--npm-11-18-linked-install-strategy-stable-phantom-deps.png"
author: lschvn
tags: ["tooling", "ecosystem"]
tldr:
  - "[npm 11.18.0](https://github.com/npm/cli/releases/tag/v11.18.0) (29. Juni 2026) befördert `--install-strategy=linked` über die [PR #9677](https://github.com/npm/cli/pull/9677) (Backport der [PR #9674](https://github.com/npm/cli/pull/9674)) von experimentell auf stabil. Der Modus wurde in der [PR #6078](https://github.com/npm/cli/pull/6078) am 25. Januar 2023 zur RFC [npm/rfcs#0042](https://github.com/npm/rfcs/blob/main/accepted/0042-isolated-mode.md) hinzugefügt und seither durchgehend als experimentell getaggt. Die Beförderung nimmt die implizite Warnung „dies könnte Ihr node_modules fressen“, die die Doku drei Jahre und fünf Monate lang getragen hat, und ist das Schlusskapitel der Isolated-Mode-Arbeit, die das npm-Team auf dem Contributor Summit 2022 begonnen hat."
  - "Die Release liefert den neuen Top-Level-Befehlsnamensraum `npm install-scripts` ([#9635](https://github.com/npm/cli/pull/9635), Backport von [#9629](https://github.com/npm/cli/pull/9629)) mit `approve`, `deny` und `ls`. Die alten Befehle `npm approve-scripts` und `npm deny-scripts` bleiben für eine Release als Alias erhalten. Die Release fügt außerdem `install-scripts: prune unused allowScripts entries` ([#9662](https://github.com/npm/cli/pull/9662)) hinzu, `npm sbom` prozent-encodiert den `vcs_url`-Qualifier in generierten Purls ([#9693](https://github.com/npm/cli/pull/9693)), und `npm audit fix` warnt nun explizit, wenn `minimumReleaseAge` den ansonsten anwendbaren Fix blockiert ([#9564](https://github.com/npm/cli/pull/9564))."
  - "Um die Beförderung herum sind 19 der 43 Commits Bugfixes für die `linked`-Strategie selbst: Audit-Determinismus unter linked (#9638), Audit des nicht-isolierten Baums unter der linked-Strategie (#9631), verwaiste `.bin`-Shims nach Uninstall (#9643), Aufräumen veralteter `.store`- und hoisted-Verzeichnisse beim Strategiewechsel (#9649), ungültiger `filterNode`-Crash (#9645), Reparatur falsch-aber-existierender Symlink-Ziele (#9644), peerOptional-Validierung in No-Save-Mutationen (#9641), `npm exec` löst Workspace-lokale Bins unter linked auf (#9648), und `npm query` meldet den logischen Abhängigkeitsort unter linked (#9664). Zusammengenommen machen sie `linked` zu einer brauchbaren Alternative zur Standardstrategie `hoisted` für die tägliche Entwicklung, und nicht nur für CI-Smoke-Tests."
faq:
  - question: "Was ändert die `linked`-Installationsstrategie konkret?"
    answer: "Die Standardstrategie `hoisted` dupliziert transitive Abhängigkeiten in das oberste `node_modules`, sodass jedes Paket jede beliebige transitive Abhängigkeit, die zufällig gehoistet wurde, `require`n 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 zufällig 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 `import`en 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."
  - question: "Warum ist das eine große Sache, wenn die Strategie seit 2023 existiert?"
    answer: "Drei Gründe. Erstens war die Strategie drei Jahre und fünf Monate lang als experimentell getaggt, was den meisten Teams einen guten Grund gab, sich in Produktion nicht darauf zu verlassen: Eine stabile Strategie ist eine Strategie, die man in `~/.npmrc` eintragen und vergessen kann. Zweitens brachte das experimentelle-Flag scharfe Kanten mit sich: Das Audit war unter linked unzuverlässig (#9609), `npm ls` meldete falsche `UNMET DEPENDENCY`-Einträge (#9095), `npm install --audit` lieferte Null Ergebnisse bei einer echten Schwachstelle (#9609), und `napi-postinstall` konnte eine installierte optionale Native-Bindung nicht auflösen (#9620). Die 19 Bugfixes in 11.18 schließen diese Lücken. Drittens empfiehlt die npm-Doku `linked` nun aktiv für Paketautoren in CI ([PR #9690](https://github.com/npm/cli/pull/9690)): Die Doku-Seite sagt „Wir empfehlen Paketautoren, `--install-strategy=linked` während der Entwicklung zu verwenden, um nicht deklarierte (`phantom`) Abhängigkeiten vor dem Veröffentlichen abzufangen.“"
  - question: "Was ist `npm install-scripts` und was ändert sich für mich?"
    answer: "`npm install-scripts` ist ein neuer Top-Level-Befehlsnamensraum, der durch [PR #9635](https://github.com/npm/cli/pull/9635) (Backport von [#9629](https://github.com/npm/cli/pull/9629)) eingeführt wird. Er besitzt drei Unterbefehle: `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 auch die Install-, Rebuild- und `strict-allow-scripts`-Hinweise auf die neuen Befehle um. 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. Die Release fügt zudem `install-scripts: prune unused allowScripts entries` ([#9662](https://github.com/npm/cli/pull/9662)) hinzu, sodass die Allow-Liste schrumpft, wenn Pakete aus `dependencies` entfernt werden."
  - question: "Was macht die neue `min-release-age`-Warnung beim Audit-Fix?"
    answer: "[PR #9564](https://github.com/npm/cli/pull/9564) (Backport von [#9544](https://github.com/npm/cli/pull/9544)) bringt `npm audit fix` bei, zu erkennen, wenn der ansonsten anwendbare Fix durch die in `.npmrc` gesetzte `minimumReleaseAge`-Policy blockiert wird (dieselbe Policy, die [Astro 6.4.4](/articles/2026-06-05--astro-6-4-4-routing-i18n-dev-fixes) in seinem eigenen Update-Flow anzeigt). Wenn der Fix durch die Policy blockiert wird, gibt npm 11.18 eine explizite Warnung aus, die sagt, welches Paket übersprungen würde und welches Policy-Flag es blockiert, statt stillschweigend nichts zu tun. Dieselbe Policy wurde in [pnpm 11.8](/articles/2026-06-19--pnpm-11-8-dry-run-install-node-package-map-sbom) ausgeliefert und gehört nun zur Baseline jedes Paketmanagers, der sich mit Monorepo-Besitzern abstimmen will, die neue Releases für ein Cool-down-Fenster sperren."
  - question: "Wie verhält sich das zu pnpm und yarn?"
    answer: "pnpm verwendet seit der ersten Release des Projekts im Jahr 2017 standardmäßig ein isoliertes Layout und hat das experimentelle-Flag nie getragen: Jedes Paket kann nur das `require`n, was es deklariert hat, und Phantom-Abhängigkeiten sind konstruktionsbedingt unmöglich. Yarn berry (Yarn 2+) liefert einen ähnlichen `nodeLinker: pnp`-Modus und eine `nmHoistingLimits`-Einstellung, die Isolation approximiert. Der `linked`-Modus von npm ist das npm-Pendant dieser beiden Ansätze, und 11.18 ist die Release, in der npm bereit ist, ihn als tägliche Installationsstrategie für Paketautoren zu empfehlen, genau wie pnpm es tut. Die drei Paketmanager sind sich nun beim Installationsmodell einig; der Unterschied ist, welcher Standard ist: pnpm (isoliert, nie experimentell), yarn berry (PnP als Default, hoisted opt-in), npm hoisted (linked opt-in)."
  - question: "Kann ich heute gefahrlos auf npm 11.18 aktualisieren?"
    answer: "Für die überwiegende Mehrheit der Projekte ja: Die Standardstrategie `hoisted` bleibt unverändert, die Änderungen der CLI-Oberfläche sind additiv (neuer `npm install-scripts`-Namensraum, Aliasse bleiben für eine Release erhalten), und die SBOM-, Audit- und `npm ls`-Pfade erhalten Bugfixes, die die Korrektheit verbessern. Die zwei Gründe zu warten sind (1) Ihr Projekt hängt von einem Paket ab, das einen Install-Hook auf eine Weise nutzt, die das neue strict-allow-scripts-Audit als inert behandelt und meldet; der [npm-Supply-Chain-Artikel vom 6. Juni](/articles/2026-06-06--npm-supply-chain-attack-red-hat-mini-shai-hulud) behandelt die einschlägigen Flags, und (2) Sie nutzen `npm link` intensiv gegen einen Workspace mit eigenem `.store`, wo das Aufräumen beim Strategiewechsel ([#9649](https://github.com/npm/cli/pull/9649)) eher eine Verhaltensänderung als ein Bugfix ist. Für alle anderen ist `npm install -g npm@11` und der neue `linked`-Modus ein Upgrade mit einem einzigen Flag."
---

[npm 11.18.0](https://github.com/npm/cli/releases/tag/v11.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](https://github.com/npm/cli/pull/9677) (Backport von [#9674](https://github.com/npm/cli/pull/9674)), die `--install-strategy=linked` von experimentell auf stabil hebt. Der Modus wurde in [PR #6078](https://github.com/npm/cli/pull/6078) am 25. Januar 2023 zur RFC [npm/rfcs#0042](https://github.com/npm/rfcs/blob/main/accepted/0042-isolated-mode.md), 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](https://github.com/npm/cli/releases/tag/v12.0.0-pre.2), 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](https://github.com/npm/cli/pull/9424) und die [linked-Mode-Beförderung](https://github.com/npm/cli/pull/9674) 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, `require`n 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 `import`en 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](https://docs.npmjs.com/cli/v11/commands/npm-install#install-strategy) 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 in `node_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](/cli/v11/using-npm/developers#catching-undeclared-phantom-dependencies).“

Dieser Satz wurde durch [PR #9690](https://github.com/npm/cli/pull/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](https://github.com/npm/cli/issues/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](https://github.com/npm/cli/issues/9609) (#9609), [`npm ls` meldet fälschlich `UNMET DEPENDENCY`](https://github.com/npm/cli/issues/9095) (#9095), [`napi-postinstall` kann eine installierte optionale Native-Bindung nicht auflösen](https://github.com/npm/cli/issues/9620) (#9620) und der [.store-Layout-Mismatch mit dem versteckten Lockfile](https://github.com/npm/cli/issues/9612) (#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](https://github.com/npm/cli/pull/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](https://github.com/npm/cli/pull/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](https://github.com/npm/cli/pull/9666) und [#9665](https://github.com/npm/cli/pull/9665) bringen der linked-Strategie bei, transitive optionale Abhängigkeiten zu laden und `dev`/`prod`-Flags innerhalb von Workspaces korrekt anzuwenden; [#9648](https://github.com/npm/cli/pull/9648) sorgt dafür, dass `npm exec` Workspace-lokale Bins auflöst; [#9669](https://github.com/npm/cli/pull/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](https://github.com/npm/cli/pull/9635) (Backport von [#9629](https://github.com/npm/cli/pull/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](https://github.com/npm/cli/pull/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](https://github.com/npm/cli/pull/9564) (Backport von [#9544](https://github.com/npm/cli/pull/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](https://pnpm.io/npmrc#minimum-release-age) ausgeliefert, und der [Astro-6.4.4](/articles/2026-06-05--astro-6-4-4-routing-i18n-dev-fixes)-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](https://github.com/npm/cli/pull/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](https://github.com/npm/cli/pull/9631) auditiert den nicht-isolierten Baum unter der linked-Strategie, sodass SBOM- und `npm audit`-Berichte beide den vollständigen Dependency-Satz erfassen. [#9641](https://github.com/npm/cli/pull/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](https://github.com/npm/cli/pull/9602) (inerte optionale Deps in `strict-allow-scripts` nicht melden), [#9607](https://github.com/npm/cli/pull/9607) (Deps ohne aufgelöste URL namentlich genehmigen) und [#9663](https://github.com/npm/cli/pull/9663) (allowScripts-Enforcement-Lücken schließen). Zusammengenommen bedeutet das, dass der in [npm 11.5](/articles/2026-06-06--npm-supply-chain-attack-red-hat-mini-shai-hulud) 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](/articles/2026-06-06--npm-supply-chain-attack-red-hat-mini-shai-hulud), 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.