This repository has been archived by the owner. It is now read-only.

npm@5.3: npm prune --production fails #17781

Closed
michaelkrone opened this Issue Jul 14, 2017 · 48 comments

Comments

Projects
None yet
@michaelkrone

michaelkrone commented Jul 14, 2017

I'm opening this issue because:

  • npm is producing an incorrect install.
  • npm is crashing.
  • npm is doing something I don't understand.
  • Other (see below for feature requests):

What's going wrong?

npm prune --production fails with npm ERR! May not delete: /path/node_modules/.bin
NODE_ENV=production npm prune fails with npm ERR! May not delete: /path/node_modules/.bin

How can the CLI team reproduce the problem?

Run NODE_ENV=production npm prune or npm prune --production in any project which has a node_modules/.bin folder with npm@5.3.0

npm@5.2.0 is working as expected.

supporting information:

  • npm -v prints: 5.3.0
  • node -v prints: v8.1.4
  • npm config get registry prints: https://registry.npmjs.org/
  • Windows, OS X/macOS, or Linux?: Linux 3.13.0-123-generic

@michaelkrone michaelkrone changed the title from npm5: npm prune --production fails to npm@5.3: npm prune --production fails Jul 14, 2017

@etremblay

This comment has been minimized.

Show comment
Hide comment
@etremblay

etremblay Jul 14, 2017

We have the same issue with npm 5.3.0

etremblay commented Jul 14, 2017

We have the same issue with npm 5.3.0

fasterthanlime added a commit to itchio/itch that referenced this issue Jul 15, 2017

fasterthanlime added a commit to fasterthanlime/grunt-electron-itchio that referenced this issue Jul 15, 2017

@fasterthanlime

This comment has been minimized.

Show comment
Hide comment
@fasterthanlime

fasterthanlime Jul 15, 2017

Contributor

A few details on how it affects us: we're shipping an Electron app for Linux/macOS/Windows.

We ship a PKGBUILD for ArchLinux - the Arch package for npm has already been upgraded to @5.3.0 - there's no way to depend on 5.2.0 specifically, so if the user already has 5.3.0 installed, the PKGBUILD will just fail on the npm prune --production part.

(Electron apps typically runnpm prune --production as part of their packaging because the devDeps just take up disk space and aren't used in production).

I've tried working around it by wiping node_modules/.bin before calling npm prune but that didn't seem to work either.

I think I'm out of workaround until npm@5.4.0 ships ☹️


Here's an npm debug log showing the failure: https://gist.github.com/fasterthanlime/d72dabfb7467f8909b95aa6e1f3e1f40


Another npm debug log right after running rm -rf node_modules: https://gist.github.com/fasterthanlime/6992fb80d4efb1235d2106c65b1f38bc


Reading the npm source, unbuild.js calls gentlyRm on npm.bin here then gentlyRm throws a gentle reminder that removing npm.bin is not allowed, here.

Neither of these files have been touched between 5.2.0 and 5.3.0 though.


Confirming that: this happens

  • (at least) on Linux & Windows (haven't tried macOS)
  • whenever the project in question depends on a package that installs something to .bin - whether or not that path actually exists on disk
    • I'm guessing that applies only to dev packages, otherwise npm prune --production wouldn't be trying to remove stuff
Contributor

fasterthanlime commented Jul 15, 2017

A few details on how it affects us: we're shipping an Electron app for Linux/macOS/Windows.

We ship a PKGBUILD for ArchLinux - the Arch package for npm has already been upgraded to @5.3.0 - there's no way to depend on 5.2.0 specifically, so if the user already has 5.3.0 installed, the PKGBUILD will just fail on the npm prune --production part.

(Electron apps typically runnpm prune --production as part of their packaging because the devDeps just take up disk space and aren't used in production).

I've tried working around it by wiping node_modules/.bin before calling npm prune but that didn't seem to work either.

I think I'm out of workaround until npm@5.4.0 ships ☹️


Here's an npm debug log showing the failure: https://gist.github.com/fasterthanlime/d72dabfb7467f8909b95aa6e1f3e1f40


Another npm debug log right after running rm -rf node_modules: https://gist.github.com/fasterthanlime/6992fb80d4efb1235d2106c65b1f38bc


Reading the npm source, unbuild.js calls gentlyRm on npm.bin here then gentlyRm throws a gentle reminder that removing npm.bin is not allowed, here.

Neither of these files have been touched between 5.2.0 and 5.3.0 though.


Confirming that: this happens

  • (at least) on Linux & Windows (haven't tried macOS)
  • whenever the project in question depends on a package that installs something to .bin - whether or not that path actually exists on disk
    • I'm guessing that applies only to dev packages, otherwise npm prune --production wouldn't be trying to remove stuff
@robjtede

This comment has been minimized.

Show comment
Hide comment
@robjtede

robjtede Jul 16, 2017

Can confirm this happens on MacOS High Sierra (10.13) too.

robjtede commented Jul 16, 2017

Can confirm this happens on MacOS High Sierra (10.13) too.

@fasterthanlime

This comment has been minimized.

Show comment
Hide comment
@fasterthanlime

fasterthanlime Jul 17, 2017

Contributor

I still haven't been able to find a workaround: this prevents us from releasing a new version of our app on some platforms. I hate to look impatient but npm is a pretty critical piece of infrastructure 😄

Any kind of status update would be super appreciated! ❤️

Contributor

fasterthanlime commented Jul 17, 2017

I still haven't been able to find a workaround: this prevents us from releasing a new version of our app on some platforms. I hate to look impatient but npm is a pretty critical piece of infrastructure 😄

Any kind of status update would be super appreciated! ❤️

@robjtede

This comment has been minimized.

Show comment
Hide comment
@robjtede

robjtede Jul 17, 2017

@fasterthanlime I was able to roll back with npm i -g npm@5.2

robjtede commented Jul 17, 2017

@fasterthanlime I was able to roll back with npm i -g npm@5.2

@fasterthanlime

This comment has been minimized.

Show comment
Hide comment
@fasterthanlime

fasterthanlime Jul 17, 2017

Contributor

@fasterthanlime I was able to roll back with npm i -g npm@5.2

Thanks! That's not applicable when releasing an install script for Arch Linux though: https://github.com/itchio/itch/blob/master/release/templates/PKGBUILD.in - if I depend on npm>=5.2, it'll install npm@5.3.0, and if it installs 5.3.0, the whole process will fail when it attempts to prune.

Contributor

fasterthanlime commented Jul 17, 2017

@fasterthanlime I was able to roll back with npm i -g npm@5.2

Thanks! That's not applicable when releasing an install script for Arch Linux though: https://github.com/itchio/itch/blob/master/release/templates/PKGBUILD.in - if I depend on npm>=5.2, it'll install npm@5.3.0, and if it installs 5.3.0, the whole process will fail when it attempts to prune.

@GianlucaBortoli

This comment has been minimized.

Show comment
Hide comment
@GianlucaBortoli

GianlucaBortoli Jul 17, 2017

I'm having this issue too, both on widows 10 x64 and on ubuntu 14.04.
I confirm that this problem does not happen with npm versions <= 5.2.

GianlucaBortoli commented Jul 17, 2017

I'm having this issue too, both on widows 10 x64 and on ubuntu 14.04.
I confirm that this problem does not happen with npm versions <= 5.2.

noffle added a commit to digidem/mapeo-desktop that referenced this issue Jul 17, 2017

build: rollback to npm@5.2.0 for Appveyor builds
This is due to a known issue with npm@5.3.0: npm/npm#17781
@bishbashbosh123

This comment has been minimized.

Show comment
Hide comment
@bishbashbosh123

bishbashbosh123 Jul 18, 2017

@GianlucaBortoli Do you mean the problem happens with npm > 5.2 ?
The problem goes away for me (win 10 x64 - trying to get electron-packager working) if I roll back with npm i -g npm@5.2. Thanks @robjtede.

bishbashbosh123 commented Jul 18, 2017

@GianlucaBortoli Do you mean the problem happens with npm > 5.2 ?
The problem goes away for me (win 10 x64 - trying to get electron-packager working) if I roll back with npm i -g npm@5.2. Thanks @robjtede.

@GianlucaBortoli

This comment has been minimized.

Show comment
Hide comment
@GianlucaBortoli

GianlucaBortoli Jul 18, 2017

@bishbashbosh123 by bad, I just fixed the comment to stress that the broken npm versions are > 5.2

GianlucaBortoli commented Jul 18, 2017

@bishbashbosh123 by bad, I just fixed the comment to stress that the broken npm versions are > 5.2

@sholladay

This comment has been minimized.

Show comment
Hide comment
@sholladay

sholladay Jul 18, 2017

I would think that a viable workaround for this would just be to run:

rm -rf node_modules package-lock.json && npm install --production

sholladay commented Jul 18, 2017

I would think that a viable workaround for this would just be to run:

rm -rf node_modules package-lock.json && npm install --production
@fasterthanlime

This comment has been minimized.

Show comment
Hide comment
@fasterthanlime

fasterthanlime Jul 19, 2017

Contributor

rm -rf node_modules package-lock.json && npm install --production

I realize you're trying to help, but:

  • removing package-lock.json is certainly not desirable (very happy that npm@5 ships something better than shrinkwrap for that)
  • if you have tools like electron-rebuild as devDependencies, it's not a viable workaround
    • first, you need to install all deps (including devs)
    • the postinstall hook triggers, rebuilding native dependencies against, for example, electron - using electron-rebuild (a devDependency)
    • you can then prune, removing electron-rebuild and other devDependencies

I'd like to highlight that this isn't just "some dude's weird setup", it's the way most electron apps are packaged for production - this bug breaks electron-packager for all npm@5.3.0 users, for example: electron-userland/electron-packager#686

Contributor

fasterthanlime commented Jul 19, 2017

rm -rf node_modules package-lock.json && npm install --production

I realize you're trying to help, but:

  • removing package-lock.json is certainly not desirable (very happy that npm@5 ships something better than shrinkwrap for that)
  • if you have tools like electron-rebuild as devDependencies, it's not a viable workaround
    • first, you need to install all deps (including devs)
    • the postinstall hook triggers, rebuilding native dependencies against, for example, electron - using electron-rebuild (a devDependency)
    • you can then prune, removing electron-rebuild and other devDependencies

I'd like to highlight that this isn't just "some dude's weird setup", it's the way most electron apps are packaged for production - this bug breaks electron-packager for all npm@5.3.0 users, for example: electron-userland/electron-packager#686

@sholladay

This comment has been minimized.

Show comment
Hide comment
@sholladay

sholladay Jul 19, 2017

happy that npm@5 ships something better than shrinkwrap for that

The package-lock and shrinkwrap are interchangeable (you can literally rename them to one another). Except, the former cannot be published, which makes it quite useless in my opinion as it is not included in the distributable tarball. I think what you are happy about, perhaps without realizing it, is the new lockfileVersion that includes subresource integrity and a few other niceties. The new format can (and should) be used with shrinkwraps. I imagine you are also happy that it is generated automatically at install time rather than via a separate command. But anyhow, you can still use my workaround without deleting package-lock.json if you want, it will still work. I included it because it is what I personally recommend for the common case of a full reinstall. Of course there are situations when that is not desirable.

if you have tools like electron-rebuild as devDependencies, it's not a viable workaround

That does look problematic. I don't know much about that tool, but I would expect there to be a mechanism to bypass the postinstall hooks. In fact, you can do this in a blunt force way with npm's --ignore-scripts. So perhaps rm -rf node_modules && npm install --production --ignore-scripts would work for you? Ideally you would be able to bypass only the postinstall script for that specific project, though (e.g. via an environment variable).

sholladay commented Jul 19, 2017

happy that npm@5 ships something better than shrinkwrap for that

The package-lock and shrinkwrap are interchangeable (you can literally rename them to one another). Except, the former cannot be published, which makes it quite useless in my opinion as it is not included in the distributable tarball. I think what you are happy about, perhaps without realizing it, is the new lockfileVersion that includes subresource integrity and a few other niceties. The new format can (and should) be used with shrinkwraps. I imagine you are also happy that it is generated automatically at install time rather than via a separate command. But anyhow, you can still use my workaround without deleting package-lock.json if you want, it will still work. I included it because it is what I personally recommend for the common case of a full reinstall. Of course there are situations when that is not desirable.

if you have tools like electron-rebuild as devDependencies, it's not a viable workaround

That does look problematic. I don't know much about that tool, but I would expect there to be a mechanism to bypass the postinstall hooks. In fact, you can do this in a blunt force way with npm's --ignore-scripts. So perhaps rm -rf node_modules && npm install --production --ignore-scripts would work for you? Ideally you would be able to bypass only the postinstall script for that specific project, though (e.g. via an environment variable).

@fasterthanlime

This comment has been minimized.

Show comment
Hide comment
@fasterthanlime

fasterthanlime Jul 19, 2017

Contributor

The package-lock and shrinkwrap are interchangeable

Right! shrinkwrap is dead, long live shrinkwrap. (I didn't realize it was a "backwards-compatible upgrade" rather than a different format, I'm not sure many npm@5 users do either!)

That does look problematic. I don't know much about that tool, but I would expect there to be a mechanism to bypass the postinstall hooks.

Ah but the thing is, we very much want to run the postinstall hooks.

Folks who develop electron apps have two versions of v8:

  • whatever lives at $(which node) (probably 8.x at the time of this writing)
  • whatever their target electron version ships (which actually contains two copies of v8 - one for the main process, which is actually patched node, and one for the renderer process, which is libchromiumcontent)

the two versions of v8 that electron ships are always synchronized, for compatibility reason (they interoperate quite a bit by default, and you can make them interoperate even more with the electron IPC api, remote requires, etc.)

However, there's a good chance that the version of v8 electron ships and the version of v8 used by $(which node) differ. When you install a node.js module with native code, npm builds it against your CLI node's v8 version. electron-rebuild rebuilds the native modules against (your target) electron's v8 version, so that you can actually require() them from your electron app.

I suppose a working workaround based on yours would be:

rm -rf node_modules
npm install --production --ignore-scripts
npm install --no-save electron-rebuild --ignore-scripts
node_modules/.bin/electron-rebuild
npm remove electron-rebuild --ignore-scripts

Although, it's starting to be a lot of trouble for what looks like a simple regression 😕


That's not to say that there isn't other, more complicated workarounds - some electron apps have a nested "app" folder that contains a second package.json - with only their production dependencies. I don't think it's realistic suggesting that as a temporary workaround for this npm@5.3.0 bug though, it's a pretty heavy change to make and comes with other problems challenges 😉

Contributor

fasterthanlime commented Jul 19, 2017

The package-lock and shrinkwrap are interchangeable

Right! shrinkwrap is dead, long live shrinkwrap. (I didn't realize it was a "backwards-compatible upgrade" rather than a different format, I'm not sure many npm@5 users do either!)

That does look problematic. I don't know much about that tool, but I would expect there to be a mechanism to bypass the postinstall hooks.

Ah but the thing is, we very much want to run the postinstall hooks.

Folks who develop electron apps have two versions of v8:

  • whatever lives at $(which node) (probably 8.x at the time of this writing)
  • whatever their target electron version ships (which actually contains two copies of v8 - one for the main process, which is actually patched node, and one for the renderer process, which is libchromiumcontent)

the two versions of v8 that electron ships are always synchronized, for compatibility reason (they interoperate quite a bit by default, and you can make them interoperate even more with the electron IPC api, remote requires, etc.)

However, there's a good chance that the version of v8 electron ships and the version of v8 used by $(which node) differ. When you install a node.js module with native code, npm builds it against your CLI node's v8 version. electron-rebuild rebuilds the native modules against (your target) electron's v8 version, so that you can actually require() them from your electron app.

I suppose a working workaround based on yours would be:

rm -rf node_modules
npm install --production --ignore-scripts
npm install --no-save electron-rebuild --ignore-scripts
node_modules/.bin/electron-rebuild
npm remove electron-rebuild --ignore-scripts

Although, it's starting to be a lot of trouble for what looks like a simple regression 😕


That's not to say that there isn't other, more complicated workarounds - some electron apps have a nested "app" folder that contains a second package.json - with only their production dependencies. I don't think it's realistic suggesting that as a temporary workaround for this npm@5.3.0 bug though, it's a pretty heavy change to make and comes with other problems challenges 😉

@sholladay

This comment has been minimized.

Show comment
Hide comment
@sholladay

sholladay Jul 19, 2017

For unrelated reasons, I just published fresh-cli, which does the reinstall trick I mentioned above. Sounds like it won't fix the electron-rebuild use case as-is, but maybe it will help someone.

sholladay commented Jul 19, 2017

For unrelated reasons, I just published fresh-cli, which does the reinstall trick I mentioned above. Sounds like it won't fix the electron-rebuild use case as-is, but maybe it will help someone.

albertzak added a commit to rslnd/rosalind that referenced this issue Jul 19, 2017

@fasterthanlime

This comment has been minimized.

Show comment
Hide comment
@fasterthanlime

fasterthanlime Jul 24, 2017

Contributor

Any news on this? It's starting to impact our users of our older versions.

Contributor

fasterthanlime commented Jul 24, 2017

Any news on this? It's starting to impact our users of our older versions.

fasterthanlime added a commit to fasterthanlime/npm that referenced this issue Jul 25, 2017

@fasterthanlime

This comment has been minimized.

Show comment
Hide comment
@fasterthanlime

fasterthanlime Jul 25, 2017

Contributor

Super easy reproduction steps

mkdir prune-test && cd prune-test
npm init -y
npm install -D yes
npm prune --production

Output:

 prune-test ツ npm prune --production
npm WARN prune-test@1.0.0 No description
npm WARN prune-test@1.0.0 No repository field.

npm ERR! May not delete: C:\msys64\home\amwenger\Dev\prune-test\node_modules\.bin

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\amwenger\AppData\Roaming\npm-cache\_logs\2017-07-25T10_20_15_408Z-debug.log
Contributor

fasterthanlime commented Jul 25, 2017

Super easy reproduction steps

mkdir prune-test && cd prune-test
npm init -y
npm install -D yes
npm prune --production

Output:

 prune-test ツ npm prune --production
npm WARN prune-test@1.0.0 No description
npm WARN prune-test@1.0.0 No repository field.

npm ERR! May not delete: C:\msys64\home\amwenger\Dev\prune-test\node_modules\.bin

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\amwenger\AppData\Roaming\npm-cache\_logs\2017-07-25T10_20_15_408Z-debug.log

fasterthanlime added a commit to fasterthanlime/npm that referenced this issue Jul 25, 2017

fasterthanlime added a commit to fasterthanlime/npm that referenced this issue Jul 25, 2017

fasterthanlime added a commit to fasterthanlime/npm that referenced this issue Jul 25, 2017

fasterthanlime added a commit to fasterthanlime/npm that referenced this issue Jul 25, 2017

@fasterthanlime

This comment has been minimized.

Show comment
Hide comment
@fasterthanlime

fasterthanlime Jul 25, 2017

Contributor

I've submitted a pull request for this: #17919

Now crossing fingers for a speedy v5.4.0 🙏

Contributor

fasterthanlime commented Jul 25, 2017

I've submitted a pull request for this: #17919

Now crossing fingers for a speedy v5.4.0 🙏

fasterthanlime added a commit to fasterthanlime/npm that referenced this issue Jul 25, 2017

@FioneraGH

This comment has been minimized.

Show comment
Hide comment
@FioneraGH

FioneraGH Jul 26, 2017

Same here with npm@5.3.0, electron-packager build failed

FioneraGH commented Jul 26, 2017

Same here with npm@5.3.0, electron-packager build failed

@KenanY KenanY added the npm5 label Jul 26, 2017

gempesaw added a commit to Sharecare/nexus-reverse-proxy that referenced this issue Jul 27, 2017

@em0ney

This comment has been minimized.

Show comment
Hide comment
@em0ney

em0ney Jul 28, 2017

Need that v5.4.0 yo!

em0ney commented Jul 28, 2017

Need that v5.4.0 yo!

@AnthonyAkentiev

This comment has been minimized.

Show comment
Hide comment
@AnthonyAkentiev

AnthonyAkentiev Aug 22, 2017

Please fix this))

AnthonyAkentiev commented Aug 22, 2017

Please fix this))

@iarna iarna closed this in 44b98b9 Aug 23, 2017

@robjtede

This comment has been minimized.

Show comment
Hide comment
@robjtede

robjtede Aug 23, 2017

🎉 🎉 🎉 🎉

robjtede commented Aug 23, 2017

🎉 🎉 🎉 🎉

kmsheng added a commit to kmsheng/npm-prune-fail that referenced this issue Aug 23, 2017

@kmsheng

This comment has been minimized.

Show comment
Hide comment
@kmsheng

kmsheng Aug 23, 2017

@iarna
This issue was not fixed properly in npm@5.4.0
I've made a repo to reproduce this issue.
https://github.com/kmsheng/npm-prune-fail
run npm i and npm prune --production

npm: 5.4.0
node: v8.1.4

kmsheng commented Aug 23, 2017

@iarna
This issue was not fixed properly in npm@5.4.0
I've made a repo to reproduce this issue.
https://github.com/kmsheng/npm-prune-fail
run npm i and npm prune --production

npm: 5.4.0
node: v8.1.4

@fasterthanlime

This comment has been minimized.

Show comment
Hide comment
@fasterthanlime

fasterthanlime Aug 23, 2017

Contributor

@kmsheng Here's what I'm seeing in the logs when trying to repro from your repo:

 3812 3203 error enoent ENOENT: no such file or directory, rename 'C:\msys64\home\amos\Dev\npm-prune-fail\node_modules\.staging\npmlog-41724339' -       > 'C:\msys64\home\amos\Dev\npm-prune-fail\node_modules\sqlite3\node_modules\node-pre-gyp\node_modules\npmlog'

This looks like a distinct issue.


the following package.json goes through npm i and npm prune --production without any problems.

{
  "name": "npm-prune-fail",
  "dependencies": {
    "lodash": "4.17.4"
  },
  "devDependencies": {
    "yes": "1.1.1"
  },
}

The issue you report @kmsheng seems to have to do with the fact that sqlite3 is a native addon (and it uses node-pre-gyp to install prebuilt binaries)

Contributor

fasterthanlime commented Aug 23, 2017

@kmsheng Here's what I'm seeing in the logs when trying to repro from your repo:

 3812 3203 error enoent ENOENT: no such file or directory, rename 'C:\msys64\home\amos\Dev\npm-prune-fail\node_modules\.staging\npmlog-41724339' -       > 'C:\msys64\home\amos\Dev\npm-prune-fail\node_modules\sqlite3\node_modules\node-pre-gyp\node_modules\npmlog'

This looks like a distinct issue.


the following package.json goes through npm i and npm prune --production without any problems.

{
  "name": "npm-prune-fail",
  "dependencies": {
    "lodash": "4.17.4"
  },
  "devDependencies": {
    "yes": "1.1.1"
  },
}

The issue you report @kmsheng seems to have to do with the fact that sqlite3 is a native addon (and it uses node-pre-gyp to install prebuilt binaries)

@GianlucaBortoli

This comment has been minimized.

Show comment
Hide comment
@GianlucaBortoli

GianlucaBortoli Aug 23, 2017

I agree with @fasterthanlime. I think that's another problem, since the log states:
ENOENT: no such file or directory, rename ...

I just run few tests with the 5.4.0 pre-release and the npm prune --production problem seems to be fixed.

GianlucaBortoli commented Aug 23, 2017

I agree with @fasterthanlime. I think that's another problem, since the log states:
ENOENT: no such file or directory, rename ...

I just run few tests with the 5.4.0 pre-release and the npm prune --production problem seems to be fixed.

@kmsheng

This comment has been minimized.

Show comment
Hide comment
@kmsheng

kmsheng Aug 23, 2017

@fasterthanlime Ok. Since it's another issue, I've opened #18277.

My logs are here.

npm ERR! path /Users/kmsheng/work/npm-prune-fail/node_modules/.staging/npmlog-d77c67cb
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall rename
npm ERR! enoent ENOENT: no such file or directory, rename '/Users/kmsheng/work/npm-prune-fail/node_modules/.staging/npmlog-d77c67cb' -> '/Users/kmsheng/work/npm-prune-fail/node_modules/sqlite3/node_modules/node-pre-gyp/node_modules/npmlog'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/kmsheng/.npm/_logs/2017-08-23T10_39_31_853Z-debug.log

kmsheng commented Aug 23, 2017

@fasterthanlime Ok. Since it's another issue, I've opened #18277.

My logs are here.

npm ERR! path /Users/kmsheng/work/npm-prune-fail/node_modules/.staging/npmlog-d77c67cb
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall rename
npm ERR! enoent ENOENT: no such file or directory, rename '/Users/kmsheng/work/npm-prune-fail/node_modules/.staging/npmlog-d77c67cb' -> '/Users/kmsheng/work/npm-prune-fail/node_modules/sqlite3/node_modules/node-pre-gyp/node_modules/npmlog'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/kmsheng/.npm/_logs/2017-08-23T10_39_31_853Z-debug.log
@leoj3n

This comment has been minimized.

Show comment
Hide comment
@leoj3n

leoj3n Aug 25, 2017

I downgraded, was able to get past this error for one build, but now getting same error with 5.2.0 on second+ runs.

leoj3n commented Aug 25, 2017

I downgraded, was able to get past this error for one build, but now getting same error with 5.2.0 on second+ runs.

@fasterthanlime

This comment has been minimized.

Show comment
Hide comment
@fasterthanlime

fasterthanlime Aug 25, 2017

Contributor

@leoj3n npm@5.4.0 is out, and fixes this particular bug - downgrading is no longer recommended.

If you do encounter problems with npm@5.4.0, please open separate issues - but first, make sure it's not a duplicate of #18277 for example.

Contributor

fasterthanlime commented Aug 25, 2017

@leoj3n npm@5.4.0 is out, and fixes this particular bug - downgrading is no longer recommended.

If you do encounter problems with npm@5.4.0, please open separate issues - but first, make sure it's not a duplicate of #18277 for example.

@leoj3n

This comment has been minimized.

Show comment
Hide comment
@leoj3n

leoj3n Aug 25, 2017

@fasterthanlime Thanks, yes that works. I had npm installed as a local dependency as well as global, and it seems both were getting used at some point, so I had to update my project local npm dep as well as global dep (this is an app that requires npm to run npm commands programmatically).

leoj3n commented Aug 25, 2017

@fasterthanlime Thanks, yes that works. I had npm installed as a local dependency as well as global, and it seems both were getting used at some point, so I had to update my project local npm dep as well as global dep (this is an app that requires npm to run npm commands programmatically).

@hostenvoy

This comment has been minimized.

Show comment
Hide comment
@hostenvoy

hostenvoy Aug 26, 2017

@fasterthanlime It works now with 5.4.0. Thanks for the info.

hostenvoy commented Aug 26, 2017

@fasterthanlime It works now with 5.4.0. Thanks for the info.

@imerkle

This comment has been minimized.

Show comment
Hide comment
@imerkle

imerkle Aug 28, 2017

wasted 1 day . npm -i -g npm@5.4 works

imerkle commented Aug 28, 2017

wasted 1 day . npm -i -g npm@5.4 works

@Metrakit

This comment has been minimized.

Show comment
Hide comment
@Metrakit

Metrakit Aug 30, 2017

@dsslimshaddy Thanks you save my day !! The right cmd is npm i -g npm@5.4 😄

Metrakit commented Aug 30, 2017

@dsslimshaddy Thanks you save my day !! The right cmd is npm i -g npm@5.4 😄

@ananthfrancis

This comment has been minimized.

Show comment
Hide comment
@ananthfrancis

ananthfrancis Aug 31, 2017

I fixed this issue by executing below command.
npm i -g npm@5.2 .

ananthfrancis commented Aug 31, 2017

I fixed this issue by executing below command.
npm i -g npm@5.2 .

@robjtede

This comment has been minimized.

Show comment
Hide comment
@robjtede

robjtede Aug 31, 2017

@ananthfrancis this specific issue has been resolved in the latest npm release 5.4. Downgrading is no longer recommended.

You may still have issues with native add-ons though in which case you should follow discussion on #18277.

robjtede commented Aug 31, 2017

@ananthfrancis this specific issue has been resolved in the latest npm release 5.4. Downgrading is no longer recommended.

You may still have issues with native add-ons though in which case you should follow discussion on #18277.

@wayofthefuture

This comment has been minimized.

Show comment
Hide comment
@wayofthefuture

wayofthefuture Sep 25, 2017

@robjtede Good luck getting npm 5.4 installed if you are using nvm-windows. Npm is non-upgradable, the perfect paradox. We are downgrading to 8.1 we have no choice.

coreybutler/nvm-windows#300

wayofthefuture commented Sep 25, 2017

@robjtede Good luck getting npm 5.4 installed if you are using nvm-windows. Npm is non-upgradable, the perfect paradox. We are downgrading to 8.1 we have no choice.

coreybutler/nvm-windows#300

@barczaG

This comment has been minimized.

Show comment
Hide comment
@barczaG

barczaG Oct 3, 2017

With npm 5.4 I got the following error:

Error: Cannot find module 'npmlog'
    at Function.Module._resolveFilename (module.js:527:15)
    at Function.Module._load (module.js:476:23)
    at Module.require (module.js:568:17)
    at require (internal/module.js:11:18)
    at /usr/local/lib/node_modules/npm/bin/npm-cli.js:22:13
    at Object.<anonymous> (/usr/local/lib/node_modules/npm/bin/npm-cli.js:92:3)
    at Module._compile (module.js:624:30)
    at Object.Module._extensions..js (module.js:635:10)
    at Module.load (module.js:545:32)
    at tryModuleLoad (module.js:508:12)

barczaG commented Oct 3, 2017

With npm 5.4 I got the following error:

Error: Cannot find module 'npmlog'
    at Function.Module._resolveFilename (module.js:527:15)
    at Function.Module._load (module.js:476:23)
    at Module.require (module.js:568:17)
    at require (internal/module.js:11:18)
    at /usr/local/lib/node_modules/npm/bin/npm-cli.js:22:13
    at Object.<anonymous> (/usr/local/lib/node_modules/npm/bin/npm-cli.js:92:3)
    at Module._compile (module.js:624:30)
    at Object.Module._extensions..js (module.js:635:10)
    at Module.load (module.js:545:32)
    at tryModuleLoad (module.js:508:12)

alrra referenced this issue in webhintio/hint Oct 5, 2017

Chore: Minor changes
* Lock version of `@types/node` to `8.0.14`
* Code style change in `release` script

alrra added a commit to webhintio/hint that referenced this issue Oct 5, 2017

Chore: Remove unneeded code from `release.ts`
Remove code that removes `node_modules/.bin/*` as the issue that
fixes was actually an issue with `npm` that is now fixed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

See: npm/npm#17781
@wgrhstf

This comment has been minimized.

Show comment
Hide comment
@wgrhstf

wgrhstf Jan 20, 2018

The Problem now occurs on npm 5.6.0 Before updating everything worked on 5.4 but now with 5.6.0 electron-packager breaks with

Error: Command failed: npm prune --production
npm ERR! path C:\Users\xxx\AppData\Local\Temp\electron-packager\linux-ia32\AppName-linux-ia32\resources\app\node_modules\npm\node_modules\dezalgo
npm ERR! code ENOENT
npm ERR! errno -4058
npm ERR! syscall rename
npm ERR! enoent ENOENT: no such file or directory, rename 'C:\Users\xxx\AppData\Local\Temp\electron-packager\linux-ia32\AppName-linux-ia32\resources\app\node_modules\npm\node_modules\dezalgo' -> 'C:\Users\xxx\AppData\Local\Temp\electron-packager\linux-ia32\AppName-linux-ia32\resources\app\node_modules\npm\node_modules\.dezalgo.DELETE'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

wgrhstf commented Jan 20, 2018

The Problem now occurs on npm 5.6.0 Before updating everything worked on 5.4 but now with 5.6.0 electron-packager breaks with

Error: Command failed: npm prune --production
npm ERR! path C:\Users\xxx\AppData\Local\Temp\electron-packager\linux-ia32\AppName-linux-ia32\resources\app\node_modules\npm\node_modules\dezalgo
npm ERR! code ENOENT
npm ERR! errno -4058
npm ERR! syscall rename
npm ERR! enoent ENOENT: no such file or directory, rename 'C:\Users\xxx\AppData\Local\Temp\electron-packager\linux-ia32\AppName-linux-ia32\resources\app\node_modules\npm\node_modules\dezalgo' -> 'C:\Users\xxx\AppData\Local\Temp\electron-packager\linux-ia32\AppName-linux-ia32\resources\app\node_modules\npm\node_modules\.dezalgo.DELETE'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent
@BMalaichik

This comment has been minimized.

Show comment
Hide comment
@BMalaichik

BMalaichik Feb 7, 2018

Have the same issue running npm prune --production

  • node 8.9.4
  • npm@5.6.0
Refusing to delete ~/.../built/node_modules/.bin/tsc: is outside ~/.../built/node_modules/typescript

BMalaichik commented Feb 7, 2018

Have the same issue running npm prune --production

  • node 8.9.4
  • npm@5.6.0
Refusing to delete ~/.../built/node_modules/.bin/tsc: is outside ~/.../built/node_modules/typescript

javihernandez added a commit to javihernandez/windows that referenced this issue Feb 26, 2018

GPII-2795: Updated to node 8.9.4 due to a problem with npm
More about the problem with the current version of npm: npm/npm#17781

generalov pushed a commit to generalov/gemini that referenced this issue Apr 7, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.