Unable to use nested local path modules

[marcellomontemagno]

npm install fails when using nested local path modules

here an example [email protected]:marcellomontemagno/npm-test.git

here a description of the dependencies between modules

moduleA
  ramda (remote)

moduleB  
  moduleA (local)
  ramda (remote)
  
moduleC
  moduleA (local)
  moduleB (local)
  ramda (remote)

Current Behavior:

Firs install of moduleC completes succesfully, removing node_modules and installing moduleC again fails.
Removing the package-lock.json works around the issue.

Expected Behavior:

npm install to complete successfully

Steps To Reproduce:

git clone [email protected]:marcellomontemagno/npm-test.git
cd npm-test/moduleA
npm i
cd ../moduleB
npm i
cd ../moduleC
npm i

workaround

cd npm-test/moduleC
rm -rf node_modules
rm package-lock.json
npm i

notice that after the workaround

cd npm-test/moduleC
rm -rf node_modules
npm i

will fail again

Environment:

• OS: Mac OC Catalina 10.15.7
• Node: v12.10.0
• npm: 6.14.11

[yancyknight]

I'm having the same problem with the following package structure and environment.

Package Structure

moduleA

• moduleB: "file:../moduleB"
• moduleC: "file:../moduleC"

moduleB

• moduleC: "file:../moduleC"

moduleC

• none

Environment (Same error on both)

OS: node:14-slim Docker image (Based on debian 9.13)
Node: v14.15.4
npm: 6.14.10

OS: CentOS 7
Node: v12.15.0
npm: 6.14.10

Error

Caused by running npm install in packageA.

... more of the same
npm WARN tar ENOENT: no such file or directory, open '/app/packageA/node_modules/.staging/core-js-0f2bfe61/modules/web.dom-collections.iterator.js'
npm WARN tar ENOENT: no such file or directory, open '/app/packageA/node_modules/.staging/core-js-0f2bfe61/modules/web.immediate.js'
npm WARN tar ENOENT: no such file or directory, open '/app/packageA/node_modules/.staging/core-js-0f2bfe61/modules/web.queue-microtask.js'
npm WARN tar ENOENT: no such file or directory, open '/app/packageA/node_modules/.staging/core-js-0f2bfe61/modules/web.timers.js'
npm WARN tar ENOENT: no such file or directory, open '/app/packageA/node_modules/.staging/core-js-0f2bfe61/modules/web.url-search-params.js'
npm WARN tar ENOENT: no such file or directory, open '/app/packageA/node_modules/.staging/core-js-0f2bfe61/modules/web.url.js'
npm ERR! code ENOTEMPTY
npm ERR! syscall rmdir
npm ERR! path /app/packageA/node_modules/.staging/lodash-ec79c79a
npm ERR! errno -39
npm ERR! ENOTEMPTY: directory not empty, rmdir '/app/packageA/node_modules/.staging/lodash-ec79c79a'

Removing package-lock.json makes the next install succeed for me as well, but subsequent installs fail again. Seems like it may be trying to install packageC twice at the same time and causing collisions?

[arieffikhrie]

I have same issue on the same structure.

@myexample/package1
  lodash (remote)

@myexample/package2
  @myexample/package1 (local)
  
@myexample/package3
  @myexample/package1 (local)
  @myexample/package2 (local)

It having an error when i try to npm i in package3 folder

For now, what ive done to make sure package-lock.json still can be commit in repo. I search inside package-lock.json for @myexample/package1, then make sure the version is using local path instead of version number

    "@myexample/package1": {
      "version": "file:../package1",
      "dev": true
    },
    "@myexample/package2": {
      "version": "file:../package2",
      "dev": true,
      "dependencies": {
        "@myexample/package1": {
          "version": "1.0.0" // change this to "version": "file:../package1"
        }
      }
    },

[yancyknight]

I tried the workaround suggested by @arieffikhrie but it looks like all my versions were already pointed to "file:../package1" instead of "1.0.0" and it still breaks when doing a fresh install with no node_modules.

[darcyclarke]

npm v6 is no longer in active development; We will continue to push security releases to v6 at our team's discretion as-per our Support Policy.

If your bug is preproducible on v7, please re-file this issue using our new issue template.

If your issue was a feature request, please consider opening a new RRFC or RFC. If your issue was a question or other idea that was not CLI-specific, consider opening a discussion on our feedback repo