[pull] latest from npm:latest by pull[bot] · Pull Request #173 · LadyK-21/cli

pull · 2026-04-17T18:25:11Z

See Commits and Changes for more details.

Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

BREAKING CHANGE: npm will no longer attempt to resolve the path to node via whichnode. process.execPath is already set by Node to the resolved real path of the node binary, so the lookup was redundant. Scripts that expected npm to override process.execPath with a PATH-resolved (potentially symlinked) node path may be affected.

…es (#9235) Fixes#9227 `npm install` hangs when a project uses `bundledDependencies` and `overrides` targeting a transitive dep shared by multiple bundled deps. In `edge.js` `satisfiedBy()`, the `inBundle` check (added in #4963) uses `rawSpec` for bundled nodes to prevent overrides from applying to pre-resolved deps inside a dependency's tarball. However, `inBundle` is also true for deps the root itself will bundle - these are freshly resolved from the registry and overrides should apply. The override was always applied at placement time (correct version installed), but the edge stayed invalid because `satisfiedBy` checked `rawSpec`. Two bundled deps sharing the overridden transitive dep would endlessly re-queue each other via REPLACE. The fix changes `inBundle` to `inDepBundle`, which is only true when the bundler is a non-root package. This preserves the #4963 behavior for deps pre-resolved inside a dependency's bundle/shrinkwrap while allowing the root's overrides to work. Note: it is unclear whether overrides _should_ be applied to deps that will be bundled or shrinkwrapped. The comment says that we explicitly don't, but I can't find supporting docs, and the existing behavior is that overrides are applied to dependencies that will be bundled/shrinkwrapped. I added tests asserting that behavior. These new tests passed without the change: - overrides do not apply inside a dependency that bundles - node bundled inside a dependency uses rawSpec - node inside a shrinkwrap uses rawSpec These new tests failed, they produced the same tree, but the edges were marked invalid: - node bundled by root uses overridden spec - overrides apply to deps the root will bundle and edges are valid This test hung forever: - does not infinite loop In both cases overrides that are 'baked into' dependnecies appear as 'invalid'. This happens because the root package doesn't read the bundler's overrides, and doesn't know why the shrinkwrap/bundle included the out-of-spec version. This commit doesn't affect that behavior.

In continuation of our exploration of using `install-strategy=linked` in the [Gutenberg monorepo](WordPress/gutenberg#75814), which powers the WordPress Block Editor. When using `install-strategy=linked`, npm overrides for transitive dependencies were ignored. The overridden version was installed but reported as `invalid` instead of `overridden`, and with `strict-peer-deps` the install failed entirely with `ERESOLVE`. The root cause is that override propagation stops at Link nodes and never reaches their targets. Overrides propagate through the tree via `addEdgeIn` -> `updateOverridesEdgeInAdded` -> `recalculateOutEdgesOverrides`. When a Link node receives overrides, `recalculateOutEdgesOverrides` iterates over `this.edgesOut` — but Links have no `edgesOut` (their targets do). So overrides never reach the target node's dependency edges, and those edges use `rawSpec` instead of the overridden spec. In the linked strategy, all packages in `node_modules/` are Links pointing to targets in `.store/`. This meant no overrides propagated past the first level of the dependency tree. The fix overrides `recalculateOutEdgesOverrides` in the `Link` class to forward overrides to the target node. When `buildIdealTree` creates a root Link (e.g. on macOS where `/tmp` -> `/private/tmp`), the target Node is now created with `loadOverrides: true` so it loads override rules from `package.json`. The `#applyRootOverridesToWorkspaces` workaround method is removed — it was compensating for this exact bug by detaching workspace edges whose specs didn't match. With proper propagation, workspace edges already have the correct overridden spec, making the workaround dead code. ## References Fixes#9197

`npx` unconditionally re-reifies `file:`/directory specs on every invocation, even when the package is already installed in the npx cache. This happens because `missingFromTree()` has an early return for directory specs that bypasses the cache lookup entirely. Registry packages correctly skip reify on cache hit by checking `node.package.resolved === manifest._resolved`, but directory specs never reach that check. The fix makes two changes to `missingFromTree()` in `libnpmexec/lib/index.js`: 1. The early return for directory specs is now scoped to non-npx trees (`!isNpxTree`), so the npx cache tree is actually consulted on subsequent runs. 2. Added `node.realpath === manifest._resolved` as an alternative match condition, since `file:` spec nodes in the npx cache have `undefined` for `package.resolved` but their `realpath` contains the matching absolute path. A regression test verifies that running `exec` twice with the same `file:` spec only triggers `reify` once (on the cold cache run). ## References Fixes#9251

LadyK-21 · 2026-04-17T18:25:44Z

⚠️Snyk checks are incomplete.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
⚠️	Open Source Security	0	0	0	0	See details

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

pull · 2026-04-17T18:25:11Z

See Commits and Changes for more details.

Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

BREAKING CHANGE: npm will no longer attempt to resolve the path to node via whichnode. process.execPath is already set by Node to the resolved real path of the node binary, so the lookup was redundant. Scripts that expected npm to override process.execPath with a PATH-resolved (potentially symlinked) node path may be affected.

…es (#9235) Fixes#9227 `npm install` hangs when a project uses `bundledDependencies` and `overrides` targeting a transitive dep shared by multiple bundled deps. In `edge.js` `satisfiedBy()`, the `inBundle` check (added in #4963) uses `rawSpec` for bundled nodes to prevent overrides from applying to pre-resolved deps inside a dependency's tarball. However, `inBundle` is also true for deps the root itself will bundle - these are freshly resolved from the registry and overrides should apply. The override was always applied at placement time (correct version installed), but the edge stayed invalid because `satisfiedBy` checked `rawSpec`. Two bundled deps sharing the overridden transitive dep would endlessly re-queue each other via REPLACE. The fix changes `inBundle` to `inDepBundle`, which is only true when the bundler is a non-root package. This preserves the #4963 behavior for deps pre-resolved inside a dependency's bundle/shrinkwrap while allowing the root's overrides to work. Note: it is unclear whether overrides _should_ be applied to deps that will be bundled or shrinkwrapped. The comment says that we explicitly don't, but I can't find supporting docs, and the existing behavior is that overrides are applied to dependencies that will be bundled/shrinkwrapped. I added tests asserting that behavior. These new tests passed without the change: - overrides do not apply inside a dependency that bundles - node bundled inside a dependency uses rawSpec - node inside a shrinkwrap uses rawSpec These new tests failed, they produced the same tree, but the edges were marked invalid: - node bundled by root uses overridden spec - overrides apply to deps the root will bundle and edges are valid This test hung forever: - does not infinite loop In both cases overrides that are 'baked into' dependnecies appear as 'invalid'. This happens because the root package doesn't read the bundler's overrides, and doesn't know why the shrinkwrap/bundle included the out-of-spec version. This commit doesn't affect that behavior.

In continuation of our exploration of using `install-strategy=linked` in the [Gutenberg monorepo](WordPress/gutenberg#75814), which powers the WordPress Block Editor. When using `install-strategy=linked`, npm overrides for transitive dependencies were ignored. The overridden version was installed but reported as `invalid` instead of `overridden`, and with `strict-peer-deps` the install failed entirely with `ERESOLVE`. The root cause is that override propagation stops at Link nodes and never reaches their targets. Overrides propagate through the tree via `addEdgeIn` -> `updateOverridesEdgeInAdded` -> `recalculateOutEdgesOverrides`. When a Link node receives overrides, `recalculateOutEdgesOverrides` iterates over `this.edgesOut` — but Links have no `edgesOut` (their targets do). So overrides never reach the target node's dependency edges, and those edges use `rawSpec` instead of the overridden spec. In the linked strategy, all packages in `node_modules/` are Links pointing to targets in `.store/`. This meant no overrides propagated past the first level of the dependency tree. The fix overrides `recalculateOutEdgesOverrides` in the `Link` class to forward overrides to the target node. When `buildIdealTree` creates a root Link (e.g. on macOS where `/tmp` -> `/private/tmp`), the target Node is now created with `loadOverrides: true` so it loads override rules from `package.json`. The `#applyRootOverridesToWorkspaces` workaround method is removed — it was compensating for this exact bug by detaching workspace edges whose specs didn't match. With proper propagation, workspace edges already have the correct overridden spec, making the workaround dead code. ## References Fixes#9197

`npx` unconditionally re-reifies `file:`/directory specs on every invocation, even when the package is already installed in the npx cache. This happens because `missingFromTree()` has an early return for directory specs that bypasses the cache lookup entirely. Registry packages correctly skip reify on cache hit by checking `node.package.resolved === manifest._resolved`, but directory specs never reach that check. The fix makes two changes to `missingFromTree()` in `libnpmexec/lib/index.js`: 1. The early return for directory specs is now scoped to non-npx trees (`!isNpxTree`), so the npx cache tree is actually consulted on subsequent runs. 2. Added `node.realpath === manifest._resolved` as an alternative match condition, since `file:` spec nodes in the npx cache have `undefined` for `package.resolved` but their `realpath` contains the matching absolute path. A regression test verifies that running `exec` twice with the same `file:` spec only triggers `reify` once (on the cold cache run). ## References Fixes#9251

LadyK-21 · 2026-04-17T18:25:44Z

⚠️Snyk checks are incomplete.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
⚠️	Open Source Security	0	0	0	0	See details

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

pull · 2026-04-17T18:25:11Z

See Commits and Changes for more details.

Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

BREAKING CHANGE: npm will no longer attempt to resolve the path to node via whichnode. process.execPath is already set by Node to the resolved real path of the node binary, so the lookup was redundant. Scripts that expected npm to override process.execPath with a PATH-resolved (potentially symlinked) node path may be affected.

…es (#9235) Fixes#9227 `npm install` hangs when a project uses `bundledDependencies` and `overrides` targeting a transitive dep shared by multiple bundled deps. In `edge.js` `satisfiedBy()`, the `inBundle` check (added in #4963) uses `rawSpec` for bundled nodes to prevent overrides from applying to pre-resolved deps inside a dependency's tarball. However, `inBundle` is also true for deps the root itself will bundle - these are freshly resolved from the registry and overrides should apply. The override was always applied at placement time (correct version installed), but the edge stayed invalid because `satisfiedBy` checked `rawSpec`. Two bundled deps sharing the overridden transitive dep would endlessly re-queue each other via REPLACE. The fix changes `inBundle` to `inDepBundle`, which is only true when the bundler is a non-root package. This preserves the #4963 behavior for deps pre-resolved inside a dependency's bundle/shrinkwrap while allowing the root's overrides to work. Note: it is unclear whether overrides _should_ be applied to deps that will be bundled or shrinkwrapped. The comment says that we explicitly don't, but I can't find supporting docs, and the existing behavior is that overrides are applied to dependencies that will be bundled/shrinkwrapped. I added tests asserting that behavior. These new tests passed without the change: - overrides do not apply inside a dependency that bundles - node bundled inside a dependency uses rawSpec - node inside a shrinkwrap uses rawSpec These new tests failed, they produced the same tree, but the edges were marked invalid: - node bundled by root uses overridden spec - overrides apply to deps the root will bundle and edges are valid This test hung forever: - does not infinite loop In both cases overrides that are 'baked into' dependnecies appear as 'invalid'. This happens because the root package doesn't read the bundler's overrides, and doesn't know why the shrinkwrap/bundle included the out-of-spec version. This commit doesn't affect that behavior.

In continuation of our exploration of using `install-strategy=linked` in the [Gutenberg monorepo](WordPress/gutenberg#75814), which powers the WordPress Block Editor. When using `install-strategy=linked`, npm overrides for transitive dependencies were ignored. The overridden version was installed but reported as `invalid` instead of `overridden`, and with `strict-peer-deps` the install failed entirely with `ERESOLVE`. The root cause is that override propagation stops at Link nodes and never reaches their targets. Overrides propagate through the tree via `addEdgeIn` -> `updateOverridesEdgeInAdded` -> `recalculateOutEdgesOverrides`. When a Link node receives overrides, `recalculateOutEdgesOverrides` iterates over `this.edgesOut` — but Links have no `edgesOut` (their targets do). So overrides never reach the target node's dependency edges, and those edges use `rawSpec` instead of the overridden spec. In the linked strategy, all packages in `node_modules/` are Links pointing to targets in `.store/`. This meant no overrides propagated past the first level of the dependency tree. The fix overrides `recalculateOutEdgesOverrides` in the `Link` class to forward overrides to the target node. When `buildIdealTree` creates a root Link (e.g. on macOS where `/tmp` -> `/private/tmp`), the target Node is now created with `loadOverrides: true` so it loads override rules from `package.json`. The `#applyRootOverridesToWorkspaces` workaround method is removed — it was compensating for this exact bug by detaching workspace edges whose specs didn't match. With proper propagation, workspace edges already have the correct overridden spec, making the workaround dead code. ## References Fixes#9197

`npx` unconditionally re-reifies `file:`/directory specs on every invocation, even when the package is already installed in the npx cache. This happens because `missingFromTree()` has an early return for directory specs that bypasses the cache lookup entirely. Registry packages correctly skip reify on cache hit by checking `node.package.resolved === manifest._resolved`, but directory specs never reach that check. The fix makes two changes to `missingFromTree()` in `libnpmexec/lib/index.js`: 1. The early return for directory specs is now scoped to non-npx trees (`!isNpxTree`), so the npx cache tree is actually consulted on subsequent runs. 2. Added `node.realpath === manifest._resolved` as an alternative match condition, since `file:` spec nodes in the npx cache have `undefined` for `package.resolved` but their `realpath` contains the matching absolute path. A regression test verifies that running `exec` twice with the same `file:` spec only triggers `reify` once (on the cold cache run). ## References Fixes#9251

LadyK-21 · 2026-04-17T18:25:44Z

⚠️Snyk checks are incomplete.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
⚠️	Open Source Security	0	0	0	0	See details

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

pull · 2026-04-17T18:25:11Z

See Commits and Changes for more details.

Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

BREAKING CHANGE: npm will no longer attempt to resolve the path to node via whichnode. process.execPath is already set by Node to the resolved real path of the node binary, so the lookup was redundant. Scripts that expected npm to override process.execPath with a PATH-resolved (potentially symlinked) node path may be affected.

…es (#9235) Fixes#9227 `npm install` hangs when a project uses `bundledDependencies` and `overrides` targeting a transitive dep shared by multiple bundled deps. In `edge.js` `satisfiedBy()`, the `inBundle` check (added in #4963) uses `rawSpec` for bundled nodes to prevent overrides from applying to pre-resolved deps inside a dependency's tarball. However, `inBundle` is also true for deps the root itself will bundle - these are freshly resolved from the registry and overrides should apply. The override was always applied at placement time (correct version installed), but the edge stayed invalid because `satisfiedBy` checked `rawSpec`. Two bundled deps sharing the overridden transitive dep would endlessly re-queue each other via REPLACE. The fix changes `inBundle` to `inDepBundle`, which is only true when the bundler is a non-root package. This preserves the #4963 behavior for deps pre-resolved inside a dependency's bundle/shrinkwrap while allowing the root's overrides to work. Note: it is unclear whether overrides _should_ be applied to deps that will be bundled or shrinkwrapped. The comment says that we explicitly don't, but I can't find supporting docs, and the existing behavior is that overrides are applied to dependencies that will be bundled/shrinkwrapped. I added tests asserting that behavior. These new tests passed without the change: - overrides do not apply inside a dependency that bundles - node bundled inside a dependency uses rawSpec - node inside a shrinkwrap uses rawSpec These new tests failed, they produced the same tree, but the edges were marked invalid: - node bundled by root uses overridden spec - overrides apply to deps the root will bundle and edges are valid This test hung forever: - does not infinite loop In both cases overrides that are 'baked into' dependnecies appear as 'invalid'. This happens because the root package doesn't read the bundler's overrides, and doesn't know why the shrinkwrap/bundle included the out-of-spec version. This commit doesn't affect that behavior.

In continuation of our exploration of using `install-strategy=linked` in the [Gutenberg monorepo](WordPress/gutenberg#75814), which powers the WordPress Block Editor. When using `install-strategy=linked`, npm overrides for transitive dependencies were ignored. The overridden version was installed but reported as `invalid` instead of `overridden`, and with `strict-peer-deps` the install failed entirely with `ERESOLVE`. The root cause is that override propagation stops at Link nodes and never reaches their targets. Overrides propagate through the tree via `addEdgeIn` -> `updateOverridesEdgeInAdded` -> `recalculateOutEdgesOverrides`. When a Link node receives overrides, `recalculateOutEdgesOverrides` iterates over `this.edgesOut` — but Links have no `edgesOut` (their targets do). So overrides never reach the target node's dependency edges, and those edges use `rawSpec` instead of the overridden spec. In the linked strategy, all packages in `node_modules/` are Links pointing to targets in `.store/`. This meant no overrides propagated past the first level of the dependency tree. The fix overrides `recalculateOutEdgesOverrides` in the `Link` class to forward overrides to the target node. When `buildIdealTree` creates a root Link (e.g. on macOS where `/tmp` -> `/private/tmp`), the target Node is now created with `loadOverrides: true` so it loads override rules from `package.json`. The `#applyRootOverridesToWorkspaces` workaround method is removed — it was compensating for this exact bug by detaching workspace edges whose specs didn't match. With proper propagation, workspace edges already have the correct overridden spec, making the workaround dead code. ## References Fixes#9197

`npx` unconditionally re-reifies `file:`/directory specs on every invocation, even when the package is already installed in the npx cache. This happens because `missingFromTree()` has an early return for directory specs that bypasses the cache lookup entirely. Registry packages correctly skip reify on cache hit by checking `node.package.resolved === manifest._resolved`, but directory specs never reach that check. The fix makes two changes to `missingFromTree()` in `libnpmexec/lib/index.js`: 1. The early return for directory specs is now scoped to non-npx trees (`!isNpxTree`), so the npx cache tree is actually consulted on subsequent runs. 2. Added `node.realpath === manifest._resolved` as an alternative match condition, since `file:` spec nodes in the npx cache have `undefined` for `package.resolved` but their `realpath` contains the matching absolute path. A regression test verifies that running `exec` twice with the same `file:` spec only triggers `reify` once (on the cold cache run). ## References Fixes#9251

LadyK-21 · 2026-04-17T18:25:44Z

⚠️Snyk checks are incomplete.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
⚠️	Open Source Security	0	0	0	0	See details

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

pull · 2026-04-17T18:25:11Z

See Commits and Changes for more details.

Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

BREAKING CHANGE: npm will no longer attempt to resolve the path to node via whichnode. process.execPath is already set by Node to the resolved real path of the node binary, so the lookup was redundant. Scripts that expected npm to override process.execPath with a PATH-resolved (potentially symlinked) node path may be affected.

…es (#9235) Fixes#9227 `npm install` hangs when a project uses `bundledDependencies` and `overrides` targeting a transitive dep shared by multiple bundled deps. In `edge.js` `satisfiedBy()`, the `inBundle` check (added in #4963) uses `rawSpec` for bundled nodes to prevent overrides from applying to pre-resolved deps inside a dependency's tarball. However, `inBundle` is also true for deps the root itself will bundle - these are freshly resolved from the registry and overrides should apply. The override was always applied at placement time (correct version installed), but the edge stayed invalid because `satisfiedBy` checked `rawSpec`. Two bundled deps sharing the overridden transitive dep would endlessly re-queue each other via REPLACE. The fix changes `inBundle` to `inDepBundle`, which is only true when the bundler is a non-root package. This preserves the #4963 behavior for deps pre-resolved inside a dependency's bundle/shrinkwrap while allowing the root's overrides to work. Note: it is unclear whether overrides _should_ be applied to deps that will be bundled or shrinkwrapped. The comment says that we explicitly don't, but I can't find supporting docs, and the existing behavior is that overrides are applied to dependencies that will be bundled/shrinkwrapped. I added tests asserting that behavior. These new tests passed without the change: - overrides do not apply inside a dependency that bundles - node bundled inside a dependency uses rawSpec - node inside a shrinkwrap uses rawSpec These new tests failed, they produced the same tree, but the edges were marked invalid: - node bundled by root uses overridden spec - overrides apply to deps the root will bundle and edges are valid This test hung forever: - does not infinite loop In both cases overrides that are 'baked into' dependnecies appear as 'invalid'. This happens because the root package doesn't read the bundler's overrides, and doesn't know why the shrinkwrap/bundle included the out-of-spec version. This commit doesn't affect that behavior.

In continuation of our exploration of using `install-strategy=linked` in the [Gutenberg monorepo](WordPress/gutenberg#75814), which powers the WordPress Block Editor. When using `install-strategy=linked`, npm overrides for transitive dependencies were ignored. The overridden version was installed but reported as `invalid` instead of `overridden`, and with `strict-peer-deps` the install failed entirely with `ERESOLVE`. The root cause is that override propagation stops at Link nodes and never reaches their targets. Overrides propagate through the tree via `addEdgeIn` -> `updateOverridesEdgeInAdded` -> `recalculateOutEdgesOverrides`. When a Link node receives overrides, `recalculateOutEdgesOverrides` iterates over `this.edgesOut` — but Links have no `edgesOut` (their targets do). So overrides never reach the target node's dependency edges, and those edges use `rawSpec` instead of the overridden spec. In the linked strategy, all packages in `node_modules/` are Links pointing to targets in `.store/`. This meant no overrides propagated past the first level of the dependency tree. The fix overrides `recalculateOutEdgesOverrides` in the `Link` class to forward overrides to the target node. When `buildIdealTree` creates a root Link (e.g. on macOS where `/tmp` -> `/private/tmp`), the target Node is now created with `loadOverrides: true` so it loads override rules from `package.json`. The `#applyRootOverridesToWorkspaces` workaround method is removed — it was compensating for this exact bug by detaching workspace edges whose specs didn't match. With proper propagation, workspace edges already have the correct overridden spec, making the workaround dead code. ## References Fixes#9197

`npx` unconditionally re-reifies `file:`/directory specs on every invocation, even when the package is already installed in the npx cache. This happens because `missingFromTree()` has an early return for directory specs that bypasses the cache lookup entirely. Registry packages correctly skip reify on cache hit by checking `node.package.resolved === manifest._resolved`, but directory specs never reach that check. The fix makes two changes to `missingFromTree()` in `libnpmexec/lib/index.js`: 1. The early return for directory specs is now scoped to non-npx trees (`!isNpxTree`), so the npx cache tree is actually consulted on subsequent runs. 2. Added `node.realpath === manifest._resolved` as an alternative match condition, since `file:` spec nodes in the npx cache have `undefined` for `package.resolved` but their `realpath` contains the matching absolute path. A regression test verifies that running `exec` twice with the same `file:` spec only triggers `reify` once (on the cold cache run). ## References Fixes#9251

LadyK-21 · 2026-04-17T18:25:44Z

⚠️Snyk checks are incomplete.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
⚠️	Open Source Security	0	0	0	0	See details

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

pull · 2026-04-17T18:25:11Z

See Commits and Changes for more details.

Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

BREAKING CHANGE: npm will no longer attempt to resolve the path to node via whichnode. process.execPath is already set by Node to the resolved real path of the node binary, so the lookup was redundant. Scripts that expected npm to override process.execPath with a PATH-resolved (potentially symlinked) node path may be affected.

…es (#9235) Fixes#9227 `npm install` hangs when a project uses `bundledDependencies` and `overrides` targeting a transitive dep shared by multiple bundled deps. In `edge.js` `satisfiedBy()`, the `inBundle` check (added in #4963) uses `rawSpec` for bundled nodes to prevent overrides from applying to pre-resolved deps inside a dependency's tarball. However, `inBundle` is also true for deps the root itself will bundle - these are freshly resolved from the registry and overrides should apply. The override was always applied at placement time (correct version installed), but the edge stayed invalid because `satisfiedBy` checked `rawSpec`. Two bundled deps sharing the overridden transitive dep would endlessly re-queue each other via REPLACE. The fix changes `inBundle` to `inDepBundle`, which is only true when the bundler is a non-root package. This preserves the #4963 behavior for deps pre-resolved inside a dependency's bundle/shrinkwrap while allowing the root's overrides to work. Note: it is unclear whether overrides _should_ be applied to deps that will be bundled or shrinkwrapped. The comment says that we explicitly don't, but I can't find supporting docs, and the existing behavior is that overrides are applied to dependencies that will be bundled/shrinkwrapped. I added tests asserting that behavior. These new tests passed without the change: - overrides do not apply inside a dependency that bundles - node bundled inside a dependency uses rawSpec - node inside a shrinkwrap uses rawSpec These new tests failed, they produced the same tree, but the edges were marked invalid: - node bundled by root uses overridden spec - overrides apply to deps the root will bundle and edges are valid This test hung forever: - does not infinite loop In both cases overrides that are 'baked into' dependnecies appear as 'invalid'. This happens because the root package doesn't read the bundler's overrides, and doesn't know why the shrinkwrap/bundle included the out-of-spec version. This commit doesn't affect that behavior.

In continuation of our exploration of using `install-strategy=linked` in the [Gutenberg monorepo](WordPress/gutenberg#75814), which powers the WordPress Block Editor. When using `install-strategy=linked`, npm overrides for transitive dependencies were ignored. The overridden version was installed but reported as `invalid` instead of `overridden`, and with `strict-peer-deps` the install failed entirely with `ERESOLVE`. The root cause is that override propagation stops at Link nodes and never reaches their targets. Overrides propagate through the tree via `addEdgeIn` -> `updateOverridesEdgeInAdded` -> `recalculateOutEdgesOverrides`. When a Link node receives overrides, `recalculateOutEdgesOverrides` iterates over `this.edgesOut` — but Links have no `edgesOut` (their targets do). So overrides never reach the target node's dependency edges, and those edges use `rawSpec` instead of the overridden spec. In the linked strategy, all packages in `node_modules/` are Links pointing to targets in `.store/`. This meant no overrides propagated past the first level of the dependency tree. The fix overrides `recalculateOutEdgesOverrides` in the `Link` class to forward overrides to the target node. When `buildIdealTree` creates a root Link (e.g. on macOS where `/tmp` -> `/private/tmp`), the target Node is now created with `loadOverrides: true` so it loads override rules from `package.json`. The `#applyRootOverridesToWorkspaces` workaround method is removed — it was compensating for this exact bug by detaching workspace edges whose specs didn't match. With proper propagation, workspace edges already have the correct overridden spec, making the workaround dead code. ## References Fixes#9197

`npx` unconditionally re-reifies `file:`/directory specs on every invocation, even when the package is already installed in the npx cache. This happens because `missingFromTree()` has an early return for directory specs that bypasses the cache lookup entirely. Registry packages correctly skip reify on cache hit by checking `node.package.resolved === manifest._resolved`, but directory specs never reach that check. The fix makes two changes to `missingFromTree()` in `libnpmexec/lib/index.js`: 1. The early return for directory specs is now scoped to non-npx trees (`!isNpxTree`), so the npx cache tree is actually consulted on subsequent runs. 2. Added `node.realpath === manifest._resolved` as an alternative match condition, since `file:` spec nodes in the npx cache have `undefined` for `package.resolved` but their `realpath` contains the matching absolute path. A regression test verifies that running `exec` twice with the same `file:` spec only triggers `reify` once (on the cold cache run). ## References Fixes#9251

LadyK-21 · 2026-04-17T18:25:44Z

⚠️Snyk checks are incomplete.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
⚠️	Open Source Security	0	0	0	0	See details

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

pull · 2026-04-17T18:25:11Z

See Commits and Changes for more details.

Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

BREAKING CHANGE: npm will no longer attempt to resolve the path to node via whichnode. process.execPath is already set by Node to the resolved real path of the node binary, so the lookup was redundant. Scripts that expected npm to override process.execPath with a PATH-resolved (potentially symlinked) node path may be affected.

…es (#9235) Fixes#9227 `npm install` hangs when a project uses `bundledDependencies` and `overrides` targeting a transitive dep shared by multiple bundled deps. In `edge.js` `satisfiedBy()`, the `inBundle` check (added in #4963) uses `rawSpec` for bundled nodes to prevent overrides from applying to pre-resolved deps inside a dependency's tarball. However, `inBundle` is also true for deps the root itself will bundle - these are freshly resolved from the registry and overrides should apply. The override was always applied at placement time (correct version installed), but the edge stayed invalid because `satisfiedBy` checked `rawSpec`. Two bundled deps sharing the overridden transitive dep would endlessly re-queue each other via REPLACE. The fix changes `inBundle` to `inDepBundle`, which is only true when the bundler is a non-root package. This preserves the #4963 behavior for deps pre-resolved inside a dependency's bundle/shrinkwrap while allowing the root's overrides to work. Note: it is unclear whether overrides _should_ be applied to deps that will be bundled or shrinkwrapped. The comment says that we explicitly don't, but I can't find supporting docs, and the existing behavior is that overrides are applied to dependencies that will be bundled/shrinkwrapped. I added tests asserting that behavior. These new tests passed without the change: - overrides do not apply inside a dependency that bundles - node bundled inside a dependency uses rawSpec - node inside a shrinkwrap uses rawSpec These new tests failed, they produced the same tree, but the edges were marked invalid: - node bundled by root uses overridden spec - overrides apply to deps the root will bundle and edges are valid This test hung forever: - does not infinite loop In both cases overrides that are 'baked into' dependnecies appear as 'invalid'. This happens because the root package doesn't read the bundler's overrides, and doesn't know why the shrinkwrap/bundle included the out-of-spec version. This commit doesn't affect that behavior.

In continuation of our exploration of using `install-strategy=linked` in the [Gutenberg monorepo](WordPress/gutenberg#75814), which powers the WordPress Block Editor. When using `install-strategy=linked`, npm overrides for transitive dependencies were ignored. The overridden version was installed but reported as `invalid` instead of `overridden`, and with `strict-peer-deps` the install failed entirely with `ERESOLVE`. The root cause is that override propagation stops at Link nodes and never reaches their targets. Overrides propagate through the tree via `addEdgeIn` -> `updateOverridesEdgeInAdded` -> `recalculateOutEdgesOverrides`. When a Link node receives overrides, `recalculateOutEdgesOverrides` iterates over `this.edgesOut` — but Links have no `edgesOut` (their targets do). So overrides never reach the target node's dependency edges, and those edges use `rawSpec` instead of the overridden spec. In the linked strategy, all packages in `node_modules/` are Links pointing to targets in `.store/`. This meant no overrides propagated past the first level of the dependency tree. The fix overrides `recalculateOutEdgesOverrides` in the `Link` class to forward overrides to the target node. When `buildIdealTree` creates a root Link (e.g. on macOS where `/tmp` -> `/private/tmp`), the target Node is now created with `loadOverrides: true` so it loads override rules from `package.json`. The `#applyRootOverridesToWorkspaces` workaround method is removed — it was compensating for this exact bug by detaching workspace edges whose specs didn't match. With proper propagation, workspace edges already have the correct overridden spec, making the workaround dead code. ## References Fixes#9197

`npx` unconditionally re-reifies `file:`/directory specs on every invocation, even when the package is already installed in the npx cache. This happens because `missingFromTree()` has an early return for directory specs that bypasses the cache lookup entirely. Registry packages correctly skip reify on cache hit by checking `node.package.resolved === manifest._resolved`, but directory specs never reach that check. The fix makes two changes to `missingFromTree()` in `libnpmexec/lib/index.js`: 1. The early return for directory specs is now scoped to non-npx trees (`!isNpxTree`), so the npx cache tree is actually consulted on subsequent runs. 2. Added `node.realpath === manifest._resolved` as an alternative match condition, since `file:` spec nodes in the npx cache have `undefined` for `package.resolved` but their `realpath` contains the matching absolute path. A regression test verifies that running `exec` twice with the same `file:` spec only triggers `reify` once (on the cold cache run). ## References Fixes#9251

LadyK-21 · 2026-04-17T18:25:44Z

⚠️Snyk checks are incomplete.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
⚠️	Open Source Security	0	0	0	0	See details

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

pull · 2026-04-17T18:25:11Z

See Commits and Changes for more details.

Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

BREAKING CHANGE: npm will no longer attempt to resolve the path to node via whichnode. process.execPath is already set by Node to the resolved real path of the node binary, so the lookup was redundant. Scripts that expected npm to override process.execPath with a PATH-resolved (potentially symlinked) node path may be affected.

…es (#9235) Fixes#9227 `npm install` hangs when a project uses `bundledDependencies` and `overrides` targeting a transitive dep shared by multiple bundled deps. In `edge.js` `satisfiedBy()`, the `inBundle` check (added in #4963) uses `rawSpec` for bundled nodes to prevent overrides from applying to pre-resolved deps inside a dependency's tarball. However, `inBundle` is also true for deps the root itself will bundle - these are freshly resolved from the registry and overrides should apply. The override was always applied at placement time (correct version installed), but the edge stayed invalid because `satisfiedBy` checked `rawSpec`. Two bundled deps sharing the overridden transitive dep would endlessly re-queue each other via REPLACE. The fix changes `inBundle` to `inDepBundle`, which is only true when the bundler is a non-root package. This preserves the #4963 behavior for deps pre-resolved inside a dependency's bundle/shrinkwrap while allowing the root's overrides to work. Note: it is unclear whether overrides _should_ be applied to deps that will be bundled or shrinkwrapped. The comment says that we explicitly don't, but I can't find supporting docs, and the existing behavior is that overrides are applied to dependencies that will be bundled/shrinkwrapped. I added tests asserting that behavior. These new tests passed without the change: - overrides do not apply inside a dependency that bundles - node bundled inside a dependency uses rawSpec - node inside a shrinkwrap uses rawSpec These new tests failed, they produced the same tree, but the edges were marked invalid: - node bundled by root uses overridden spec - overrides apply to deps the root will bundle and edges are valid This test hung forever: - does not infinite loop In both cases overrides that are 'baked into' dependnecies appear as 'invalid'. This happens because the root package doesn't read the bundler's overrides, and doesn't know why the shrinkwrap/bundle included the out-of-spec version. This commit doesn't affect that behavior.

In continuation of our exploration of using `install-strategy=linked` in the [Gutenberg monorepo](WordPress/gutenberg#75814), which powers the WordPress Block Editor. When using `install-strategy=linked`, npm overrides for transitive dependencies were ignored. The overridden version was installed but reported as `invalid` instead of `overridden`, and with `strict-peer-deps` the install failed entirely with `ERESOLVE`. The root cause is that override propagation stops at Link nodes and never reaches their targets. Overrides propagate through the tree via `addEdgeIn` -> `updateOverridesEdgeInAdded` -> `recalculateOutEdgesOverrides`. When a Link node receives overrides, `recalculateOutEdgesOverrides` iterates over `this.edgesOut` — but Links have no `edgesOut` (their targets do). So overrides never reach the target node's dependency edges, and those edges use `rawSpec` instead of the overridden spec. In the linked strategy, all packages in `node_modules/` are Links pointing to targets in `.store/`. This meant no overrides propagated past the first level of the dependency tree. The fix overrides `recalculateOutEdgesOverrides` in the `Link` class to forward overrides to the target node. When `buildIdealTree` creates a root Link (e.g. on macOS where `/tmp` -> `/private/tmp`), the target Node is now created with `loadOverrides: true` so it loads override rules from `package.json`. The `#applyRootOverridesToWorkspaces` workaround method is removed — it was compensating for this exact bug by detaching workspace edges whose specs didn't match. With proper propagation, workspace edges already have the correct overridden spec, making the workaround dead code. ## References Fixes#9197

`npx` unconditionally re-reifies `file:`/directory specs on every invocation, even when the package is already installed in the npx cache. This happens because `missingFromTree()` has an early return for directory specs that bypasses the cache lookup entirely. Registry packages correctly skip reify on cache hit by checking `node.package.resolved === manifest._resolved`, but directory specs never reach that check. The fix makes two changes to `missingFromTree()` in `libnpmexec/lib/index.js`: 1. The early return for directory specs is now scoped to non-npx trees (`!isNpxTree`), so the npx cache tree is actually consulted on subsequent runs. 2. Added `node.realpath === manifest._resolved` as an alternative match condition, since `file:` spec nodes in the npx cache have `undefined` for `package.resolved` but their `realpath` contains the matching absolute path. A regression test verifies that running `exec` twice with the same `file:` spec only triggers `reify` once (on the cold cache run). ## References Fixes#9251

LadyK-21 · 2026-04-17T18:25:44Z