Skip to content

[BUG] install with --install-links and local path dependencies "dedups" packages even when the local path is different #8364

Open

Description

@Daniel-Khodabakhsh

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

  1. Download, unzip, and chdir into test.zip
  2. Delete broken/node_modules/ and broken/package-lock.json
  3. In all of the 11 broken/**/package.json files (including broken/package.json) replace all occurances of C:/Users/Dan/test/broken with $(pwd)/broken
  4. cd into broken and run npm --install-links install
  5. Navigate to the newly created node_modules and notice the missing is-plain-object version 2.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\Dan

This also happens on Guix System (Linux) with NPM 10.9.2

Activity

  1. Daniel-Khodabakhsh commented on Jun 13, 2025

    @Daniel-Khodabakhsh
    Author

    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).

  2. changed the title [-][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[/+] on Jun 18, 2025
  3. v-mragunandhan24 commented on Dec 30, 2025

    @v-mragunandhan24

    @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.4 of is-plain-object. Please find the screenshot attached.

    Image

    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"

  4. v-mragunandhan24 commented on Jan 5, 2026

    @v-mragunandhan24

    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.

  5. Daniel-Khodabakhsh commented on Jan 5, 2026

    @Daniel-Khodabakhsh
    Author

    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:

    C:\Users\Dan\test\broken>npm --install-links install
    npm error code ENOENT
    npm error syscall open
    npm error path C:\Users\Dan\test\broken\local-repo\copy-props\ers\Dan\test\broken\local-repo\each-props\package.json
    npm error errno -4058
    npm error enoent Could not read package.json: Error: ENOENT: no such file or directory, open 'C:\Users\Dan\test\broken\local-repo\copy-props\ers\Dan\test\broken\local-repo\each-props\package.json'
    npm error enoent This is related to npm not being able to find a file.
    npm error enoent
    npm error A complete log of this run can be found in: C:\Users\Dan\AppData\Local\npm-cache\_logs\2026-01-05T20_11_56_695Z-debug-0.log
    

    In my steps to reproduce I used absolute paths, not relative ones. In the steps to reproduce 3 it says to use pwd which 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

  6. Daniel-Khodabakhsh commented on Jan 22, 2026

    @Daniel-Khodabakhsh
    Author

    Tested it in Ubuntu as well, similar error message:

    /mnt/c/Users/Dan/test/broken$ npm --install-links install
    npm error code ENOENT
    npm error syscall open
    npm error path /mnt/c/Users/Dan/test/broken/local-repo/copy-props/c/Users/Dan/test/broken/local-repo/each-props/package.json
    npm error errno -2
    npm error enoent Could not read package.json: Error: ENOENT: no such file or directory, open '/mnt/c/Users/Dan/test/broken/local-repo/copy-props/c/Users/Dan/test/broken/local-repo/each-props/package.json'
    npm error enoent This is related to npm not being able to find a file.
    npm error enoent
    npm error A complete log of this run can be found in: /home/dan/.npm/_logs/2026-01-22T10_04_11_342Z-debug-0.log
    

    Can you please reopen this @MRagunandhan24 ?

    This is happened for absolute paths as per the steps the reproduce

  7. Daniel-Khodabakhsh commented on Jan 22, 2026

    @Daniel-Khodabakhsh
    Author

    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.

  8. owlstronaut commented on Jan 22, 2026

    @owlstronaut

    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.

    @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.

  9. owlstronaut commented on Jan 22, 2026

    @owlstronaut

    @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?

  10. v-mragunandhan24 commented on Jan 22, 2026

    @v-mragunandhan24

    Sure @owlstronaut, I'll check and post my findings.

  11. Daniel-Khodabakhsh commented on Feb 2, 2026

    @Daniel-Khodabakhsh
    Author

    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?

  12. added
    Bugthing that needs fixing
    and removed on Feb 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Bugthing that needs fixing

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions