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

(John Bragiel) #1

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

  • a package with bundled dependencies which depended on
    • a package with an npm-shrinkwrap.json file which depended on
      • a package with a scope

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

(Lars Willighagen) #2

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.

(John Bragiel) #3

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.