[BUG] Dependencies with local file dependencies result in invalid lockfiles #6860
Labels
Bug
thing that needs fixing
Priority 2
secondary priority issue
Release 9.x
work is associated with a specific npm 9 release
Release 10.x
Is there an existing issue for this?
This issue exists in the latest npm version
Current Behavior
Installing a dependency that contains a local file dependency works but results in an invalid (?)
package-lock.json
. Installing the same dependency again results in the following error:Expected Behavior
Installing and re-installing/updating dependencies that contain local file dependencies works without issues.
Steps To Reproduce
I've set up an example package at cascornelissen/test-npm-package. All it contains is a single local file dependency that's in the subdirectory of the repository.
mkdir ./test-npm && cd ./test-npm && npm init -y
npm install github:cascornelissen/test-npm-package
npm install github:cascornelissen/test-npm-package
install-links
The steps above assume the
install-links
option is set tofalse
(which is the current default value). It does work when executing thenpm install
command with--install-links=true
.Error
The stack trace (included below) refers to this line in
calc-dep-flags.js
where it's assumed thatnode.target
exists but it does not in this scenario. I've tried patching in a check to make surenode.target
exists but this happens in at least 5 different places, both in this file and in other files, so my assumption then became that the target should exist.Stack trace
Lockfile
Looking into the lockfile I noticed there's a package listed at
node_modules/test-npm-package/subdependency
which contains no data.For good measure, here's what the same part of the lockfile looks like with
--install-links
set totrue
.Conclusion
To me it feels like there's an issue in the generation of the lockfile,
node_modules/test-npm-package/subdependency
should be pointing to something, no? I'll investigate a bit further but wanted to create this ticket already, since maybe someone with more contextual knowledge has an answer.Related issues
file:
dependency is locked without package name when install is run for the 1st time #6430 seems to have a similar use-case but it's about a different propertynode_modules/
works as a workaround, which doesn't work in this scenario8.16.0
Environment
10.1.0
20.5.0
The text was updated successfully, but these errors were encountered: