[BUG] Invalid package when using overrides within workspaces

[clewisln]

Is there an existing issue for this?

• I have searched the existing issues

This issue exists in the latest npm version

• I am using the latest npm

This is not just a request to bump a dependency for a CVE

• This is not solely a request to bump a dependency for a CVE

Current Behavior

When overriding a package sub-dependency installed in multiple workspaces, invalid packages occur. With the override in place, npm install works without error and packages are correctly overridden. However, listing the overridden package shows an 'invalid' error and performing an npm upgrade will effectively ignore the override which can lead to installing the original non-overridden version.

This behavior does not occur in latest 10.x version of npm (10.9.8), included with latest 22.x LTS. The behavior only began to occur after upgrading to latest 11.x version of npm (11.13.0), which is included in the latest 24.x LTS.

Please see the attached isolated reproduction archive for a minimal test case.

This test case globally overrides the 'uuid' package in the root:

  "overrides": {
    "uuid@<14.0.0": {
      ".": "^14.0.0"
    }
  }

Upon a clean install, listing the overridden package results in an output similar to the following:

PS C:\scratchspace\override-test> npm ls uuid
override-test@ C:\scratchspace\override-test
├─┬ @example/a@ -> .\testa
│ └─┬ @loopback/core@7.0.12
│   └─┬ @loopback/context@8.0.12
│     ├─┬ hyperid@3.3.0
│     │ └── uuid@14.0.0 deduped invalid: "^8.3.2" from node_modules/sockjs, "^8.3.2" from node_modules/hyperid
│     └── uuid@14.0.0 invalid: "^8.3.2" from node_modules/sockjs, "^8.3.2" from node_modules/hyperid
└─┬ @example/b@ -> .\testb
  └─┬ webpack-dev-server@5.2.4
    └─┬ sockjs@0.3.24
      └── uuid@14.0.0 deduped invalid: "^8.3.2" from node_modules/sockjs

If 'npm upgrade' is done, then the package versions are reverted to the original non-overridden version:

PS C:\scratchspace\override-test> npm ls uuid
override-test@ C:\scratchspace\override-test
├─┬ @example/a@ -> .\testa
│ └─┬ @loopback/core@7.0.12
│   └─┬ @loopback/context@8.0.12
│     ├─┬ hyperid@3.3.0
│     │ └── uuid@8.3.2
│     └── uuid@14.0.0
└─┬ @example/b@ -> .\testb
  └─┬ webpack-dev-server@5.2.4
    └─┬ sockjs@0.3.24
      └── uuid@8.3.2

Expected Behavior

When overriding packages, no error should occur when listing packages and npm upgrade should continue to honor the override.

Steps To Reproduce

Isolated Reproduction (zip archive)

1. Use npm 11.13.0
2. Setup two workspaces that include a dependency, where a sub-dependency must be overridden. For this example, we will install '@loopback/core' into the first workspace and 'webpack-dev-server' into the second.
3. In the root package add an override for the sub-dependency. For this example, we will override 'uuid' globally to latest version.
4. Ensure a clean distribution by removing any existing lock file or cached node_modules
5. npm install
6. npm ls package_name. Verify package integrity
7. npm upgrade. Verify version of overridden package

Environment

• npm: 11.13.0
• Node.js: 24.16.0
• OS Name: Windows 11
• System Model Name: n/a
• npm config:

; node bin location = C:\Program Files\nodejs\node.exe
; node version = v24.16.0
; npm local prefix = C:\scratchspace\override-test
; npm version = 11.13.0
; cwd = C:\scratchspace\override-test
; HOME = C:\Users\myuser
; Run `npm config ls -l` to show all defaults.

[beanscg]

I independently reproduced the npm 11 behavior from the attached example.zip repro.

Environment:

• macOS 26.5 arm64
• node@24.16.0 via npx -p node@24.16.0
• npm@11.13.0 and npm@11.16.0 via npx -p
• NPM_CONFIG_IGNORE_SCRIPTS=true for the install/upgrade runs

Commands used from a fresh extracted copy:

npx -y -p node@24.16.0 -p npm@11.13.0 npm install
npx -y -p node@24.16.0 -p npm@11.13.0 npm ls uuid --all
npx -y -p node@24.16.0 -p npm@11.13.0 npm upgrade
npx -y -p node@24.16.0 -p npm@11.13.0 npm ls uuid --all

Result with npm@11.13.0:

• install: exit 0
• ls after install: exit 1, ELSPROBLEMS
• The invalid node was uuid@14.0.0, with the peer/requested range still shown as ^8.3.2 from sockjs and hyperid
• upgrade: exit 0
• ls after upgrade: exit 0, but the graph had reverted two paths to uuid@8.3.2

Relevant lines after install:

│     │ └── uuid@14.0.0 deduped invalid: "^8.3.2" from node_modules/sockjs, "^8.3.2" from node_modules/hyperid
│     └── uuid@14.0.0 invalid: "^8.3.2" from node_modules/sockjs, "^8.3.2" from node_modules/hyperid
      └── uuid@14.0.0 deduped invalid: "^8.3.2" from node_modules/sockjs
npm error code ELSPROBLEMS

Relevant lines after upgrade:

│     │ └── uuid@8.3.2
│     └── uuid@14.0.0
      └── uuid@8.3.2

I also reran the same sequence with npm@11.16.0, which is the current published npm version returned by npm view npm version during my test. The result was the same: npm ls uuid --all failed with uuid@14.0.0 invalid after install, and after npm upgrade two paths were back at uuid@8.3.2.

I did not verify the Windows-specific control case here; this is a macOS reproduction confirming that the npm 11 behavior is still present in 11.16.0.