Part of #9608.
Is there an existing issue for this?
This issue exists in the latest npm version
This is not just a request to bump a dependency for a CVE
Current Behavior
Under install-strategy=linked, if a top-level node_modules/<dep> symlink points to a store key that exists on disk but is the wrong version, re-running npm install does not repair it. npm reports success and leaves the dependency resolving to the wrong version. This is the on-disk state an interrupted npm install / npm update can leave behind (the new store entry is extracted, but the symlink is not yet repointed). When the symlink instead points to a non-existent target, npm install / npm ci do repair it — so the problem is specific to a wrong target that happens to exist on disk.
Expected Behavior
npm install should detect that an existing symlink points to the wrong store target and repoint it to the version required by the tree (as the hoisted strategy self-heals an equivalent corruption).
Steps To Reproduce
cd "$(mktemp -d)"
echo 'install-strategy=linked' > .npmrc
cat > package.json <<'EOF'
{ "name": "nat2", "version": "1.0.0",
"dependencies": { "minimatch": "3.1.0", "glob": "10.3.10" } }
EOF
npm install >/dev/null # store now has minimatch@3.1.0 (root) AND minimatch@9.x (via glob)
# Simulate an interrupted update: repoint the root symlink at the wrong (but existing) store key
OKEY=$(ls node_modules/.store | grep '^minimatch@9')
rm node_modules/minimatch
ln -s ".store/$OKEY/node_modules/minimatch" node_modules/minimatch
npm install # exits 0, reports success
readlink node_modules/minimatch
# .store/minimatch@9.0.9-.../node_modules/minimatch <-- NOT repaired
grep version node_modules/minimatch/package.json # -> 9.0.9, expected 3.1.0
Environment
- npm: 12.0.0-pre.1 (
latest)
- Node.js: v24.17.0
- OS Name: macOS (Darwin 25.5.0)
- System Model Name: MacBook (arm64)
- npm config:
Part of #9608.
Is there an existing issue for this?
This issue exists in the latest npm version
This is not just a request to bump a dependency for a CVE
Current Behavior
Under
install-strategy=linked, if a top-levelnode_modules/<dep>symlink points to a store key that exists on disk but is the wrong version, re-runningnpm installdoes not repair it. npm reports success and leaves the dependency resolving to the wrong version. This is the on-disk state an interruptednpm install/npm updatecan leave behind (the new store entry is extracted, but the symlink is not yet repointed). When the symlink instead points to a non-existent target,npm install/npm cido repair it — so the problem is specific to a wrong target that happens to exist on disk.Expected Behavior
npm installshould detect that an existing symlink points to the wrong store target and repoint it to the version required by the tree (as the hoisted strategy self-heals an equivalent corruption).Steps To Reproduce
Environment
latest)install-strategy=linked