Repository navigation
[BUG] install with --install-links and local path dependencies "dedups" packages even when the local path is different #8364
Description
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
Current Behavior
Using a local registry, where all package versions use local paths, and installing with --install-links, packages that are referenced multiple times get deduped even though they are different versions (in this case, have a different local path).
Consider package copy-props 2.0.5.
This package has the following truncated dependency tree, where there are two versions of is-plain-object used, 2.0.4 and 5.0.0:
copy-props (2.0.5)
├── each-props (1.3.2)
│ ├── is-plain-object (2.0.4)
│ └── ...
└── is-plain-object (5.0.0)
Normally this has the following tree when installed via the NPM registry, where you can see both version 2.0.4 and 5.0.0 of is-plain-object present in node_modules:
.
├── node_modules
│ ├── array-each
│ │ └── ...
│ ├── array-slice
│ │ └── ...
│ ├── copy-props
│ │ └── ...
│ ├── each-props
│ │ ├── node_modules
│ │ │ └── is-plain-object <------------- 2.0.4
│ │ │ └── ...
│ │ └── ...
│ ├── for-in
│ │ └── ...
│ ├── for-own
│ │ └── ...
│ ├── isobject
│ │ └── ...
│ ├── is-plain-object <------------------- 5.0.0
│ │ └── ...
│ └── object.defaults
│ └── ...
└── ...
However, if you create your own local registry with all of these packages available, and use local paths to define the package version in the list of dependencies in package.json, and if you use --install-links option, the resulting node_modules structure is as follows, where it's missing version 2.0.4 of is-plain-object:
.
├── node_modules
│ ├── array-each
│ │ └── ...
│ ├── array-slice
│ │ └── ...
│ ├── copy-props
│ │ └── ...
│ ├── each-props <- ⚠️ no inner node_modules, no is-plain-object 2.0.4
│ │ └── ...
│ ├── for-in
│ │ └── ...
│ ├── for-own
│ │ └── ...
│ ├── isobject
│ │ └── ...
│ ├── is-plain-object <-------------------------- 5.0.0
│ │ └── ...
│ └── object.defaults
│ └── ...
└── ...
In the above example, here is an excerpt from various package.json files in the local registry:
local-repo/copy-props/package.json:
{
"dependencies": {
"each-props": "/path/to/local-repo/each-props",
"is-plain-object": "/path/to/local-repo/is-plain-object@5"
}
}local-repo/each-props/package.json:
{
"dependencies": {
"is-plain-object": "/path/to/local-repo/is-plain-object@2",
"object.defaults": "/path/to/local-repo/object.defaults"
}
}If the user does NOT use --install-links, both versions 2.0.4 and 5.0.0 are installed.
Expected Behavior
Regardless if using --install-links or not, when using npm install with a local registry using local paths, the output node_modules files structure should be the same (except with installed files instead of symlinks).
Steps To Reproduce
- Download, unzip, and chdir into test.zip
- Delete
broken/node_modules/andbroken/package-lock.json - In all of the 11
broken/**/package.jsonfiles (includingbroken/package.json) replace all occurances ofC:/Users/Dan/test/brokenwith$(pwd)/broken - cd into
brokenand runnpm --install-links install - Navigate to the newly created
node_modulesand notice the missingis-plain-objectversion2.0.4
Environment
- npm: 11.3.0
- Node.js: v24.2.0
- OS Name: Windows 10
- System Model Name:
- npm config:
; node bin location = C:\Program Files\nodejs\node.exe
; node version = v24.2.0
; npm local prefix = C:\Users\Dan\test\broken
; npm version = 11.3.0
; cwd = C:\Users\Dan\test\broken
; HOME = C:\Users\DanThis also happens on Guix System (Linux) with NPM 10.9.2
Activity
Daniel-Khodabakhsh commentedon Jun 13, 2025
This issue is similar but not exactly the same as #8342. In this bug there is no error message, absolute local paths are used, and normally nested dependencies work (if the nested dependencies are unique packages, otherwise they get removed as per the description above).
[-][BUG] install --install-links with local path dependencies dedups packages even if the local path is different[/-][+][BUG] `install` with `--install-links` and local path dependencies "dedups" packages even when the local path is different[/+]v-mragunandhan24 commentedon Dec 30, 2025
@Daniel-Khodabakhsh , I tried replicating the issue using the steps provided. I was able to get the below dependency tree. I'm able to see the
v2.0.4ofis-plain-object. Please find the screenshot attached.Can you please retry using relative paths for local repo instead of absolute path in package.json and provide more details for further analysis.
Example:
In broken/package.json, modify the package.json for dependency like
"copy-props": "file:./local-repo/copy-props". Similarly for each package in local-repo, modify the package.json like"each-props": "file:../each-props"v-mragunandhan24 commentedon Jan 5, 2026
Closing due to age. If this is still a problem please feel free to reopen this issue, or create a new issue w/ steps to reproduce.
Daniel-Khodabakhsh commentedon Jan 5, 2026
Trying to validate it but there's a bug that's blocking this.
Currently with the latest version (25.2.1) an error message is shown:
In my steps to reproduce I used absolute paths, not relative ones. In the steps to reproduce 3 it says to use
pwdwhich returns the absolute path.Can test this with absolute paths @MRagunandhan24 ? This is a requirement for my use case so it's very important.
If the issue still occurs can you also go ahead and reopen this ticket? I don't have permissions to do so
Daniel-Khodabakhsh commentedon Jan 22, 2026
Tested it in Ubuntu as well, similar error message:
Can you please reopen this @MRagunandhan24 ?
This is happened for absolute paths as per the steps the reproduce
Daniel-Khodabakhsh commentedon Jan 22, 2026
Hey @owlstronaut , you investigated and fixed a similar issue #8342
Do you mind helping me reopen this bug? It's still occurring albeit with a different error message now.
owlstronaut commentedon Jan 22, 2026
@Daniel-Khodabakhsh It'll help us track better if you can create a new issue and carry over any of the relevant info for the new error, and linking to the past issue just for context. Providing an example project or exact steps for us to set up your scenario will expedite any chance we have to look for fixes.
owlstronaut commentedon Jan 22, 2026
@Daniel-Khodabakhsh Oh I see, my apologies. I see this was closed due to age, not as a duplicate. I can reopen this and have us look further.
@MRagunandhan24 could you give this a second look?
v-mragunandhan24 commentedon Jan 22, 2026
Sure @owlstronaut, I'll check and post my findings.
Daniel-Khodabakhsh commentedon Feb 2, 2026
Hey @owlstronaut , @MRagunandhan24 , I noticed this bug has the label
Awaiting Information. I've since updated the information last month. Do I need anything else to get this bug's label updated?