npm Community Forum (Archive)

The npm community forum has been discontinued.

To discuss usage of npm, visit the GitHub Support Community.

npm install failing when installing mixture of scoped, bundled, shrinkwrapped packages

Trying to npm install a package with the following criteria is failing for me (at least on Windows):

What I Wanted to Do

On Windows, install an internally developed package via:

npm install …/my-bundled-package/build/my-bundled-package-1.0.0.tgz

What Happened Instead

Package failed to install with the following error message (clipped for brevity - entire log is attached later):
npm ERR! Error: EPERM: operation not permitted, rename ‘C:\temp\npm-bug.3\my-consuming-package\node_modules\my-bundled-package\\node_modules\@babel’ -> ‘C:\temp\npm-bug.3\my-consuming-package\node_modules\my-bundled-package\node_modules\my-base-package\node_modules\@babel

Reproduction Steps

I tried to narrow this down as far as possible. The real issue is seen with installing a package published to an internal npm repository, but for recreatability, I made the scenario using local packages. There are 3 packages here which I will assume are in the following folder structure:

my-base-package/package.json file contents:

  "name": "my-base-package",
  "version": "1.0.0",
  "dependencies": {
    "@babel/code-frame": "^7.0.0"

my-bundled-package/package.json file contents:

  "name": "my-bundled-package",
  "version": "1.0.0",
  "dependencies": {
    "my-base-package": "~1.0.0"
  "bundledDependencies": [

my-consuming-package/package.json file contents:

  "name": "my-consuming-package",
  "version": "1.0.0",
  "dependencies": {
    "my-bundled-package": "~1.0.0"

Commands to run (assuming you’re starting at <base-folder>):

cd my-base-package
npm install --no-save
npm shrinkwrap
npm pack

cd ../my-bundled-package
npm install --no-save ../my-base-package/my-base-package-1.0.0.tgz
npm pack

cd ../my-consuming-package
npm install ../my-bundled-package/my-bundled-package-1.0.0.tgz


In the full failure scenario, everything had been working with this process until the addition of the scoped package as a dependency. The error message seems to indicate that the trouble is with processing the scoped package as well.

The error is happening with a rename operation (trying to rename a directory path). I was able to set a breakpoint in the npm code when the error is thrown. At this point, the target directory of the attempted rename operation already exists but is empty. If I went in and removed the target directory myself when the breakpoint hit before the rename operation, the install would work.

npm-debug.log file:
2019-02-01T19_07_44_691Z-debug.log (15.0 KB)

Platform Info

$ npm --version
{ 'my-consuming-package': '1.0.0',
  npm: '6.7.0',
  ares: '1.14.0',
  cldr: '33.1',
  http_parser: '2.8.0',
  icu: '62.1',
  modules: '64',
  napi: '3',
  nghttp2: '1.34.0',
  node: '10.14.1',
  openssl: '1.1.0j',
  tz: '2018e',
  unicode: '11.0',
  uv: '1.23.2',
  v8: '',
  zlib: '1.2.11' }

$ node -p process.platform

BTW, I was looking into this. Thanks for the detailed report! I haven’t found out anything constructive yet (I don’t think I could reproduce it on Linux yet), but this isn’t being ignored.

Thanks for the quick reply, Lars. I just tried the scenario on Linux and had the same success that you did. So, the issue is only seen on Windows.