With symlinked node_modules, running npm install changes structure of dependencis which result in changed npm-shrinkwrap.json

[dapus]

I'm opening this issue because:

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

What's going wrong?

When node_modules is a symlink that points to a directory outside of the current directory, a second npm install will produce a different structure of the dependencies in the node_modules directory.

For example, the first npm install async will produce the following structure of node_modules:

async
lodash

After running npm install, it will change to this:

async
async/node_modules/lodash

One effect of this is that the npm-shrinkwrap.json file is updated to reflect the changed directory structure, which can be a problem if it's checked in to version control.

Note that the symlink must point to somewhere outside of the current directory. If it points to somewhere in the same directory the bug cannot be reproduced.

How can the CLI team reproduce the problem?

$ mkdir -p project node_modules
$ cd project
$ ln -s ../node_modules node_modules
$ npm init --force
$ npm i async
$ ls node_modules/
async  lodash
$ npm i
$ ls node_modules/
async

supporting information:

• npm -v prints:
  5.5.1
• node -v prints:
  v8.9.1
• npm config get registry prints:
  https://registry.npmjs.org/
• Windows, OS X/macOS, or Linux?:
  Linux (Ubuntu 16.04)
• Network issues:
  • Geographic location where npm was run:
  • I use a proxy to connect to the npm registry.
  • I use a proxy to connect to the web.
  • I use a proxy when downloading Git repos.
  • I access the npm registry via a VPN
  • I don't use a proxy, but have limited or unreliable internet access.
• Container:
  • I develop using Vagrant on Windows.
  • I develop using Vagrant on OS X or Linux.
  • I develop / deploy using Docker.
  • I deploy to a PaaS (Triton, Heroku).

[x-yuri]

This is where things go wrong. When npm is trying to find lodash it first inspects async's children. But doesn't find it, since lodash is a child of top package at the moment. And this line prevents it to look among top package's children.