[BUG] install of local package differs from normal install

[RobertBeilich]

Current Behavior:

npm install of a local package does not place dependencies directly in node_modules (refer to reproduction for better explanation)

Expected Behavior:

npm install of a local package should do exactly the same as with a normal remote package

Steps To Reproduce:

git clone https://github.com/Gozala/test-commonjs.git # get a random package for testing (this one has only one dependency)
mkdir foobar && cd foobar
npm install test # shows "added 2 packages"
ls node_modules # shows ansi-font and test
npm remove test # shows "removed 2 packages"
npm install ../test-commonjs # it's the same package, but locally # shows "added 1 package"
ls node_modules # shows test (as a symlink to ../../test-commonjs)
npm remove test # shows "removed 1 package"

Use Case (in case I'm approaching this the wrong way)

Testing an eslint plugin in local development.
Eslint requires dependent plugins (npm packages) to be present directly in node_modules.

Environment:

• OS: MacOS
• npm: 7.9.0 (also 7.7.6, which is the version brew installs)

[nlf]

eslint is not able to follow the symlink? that seems strange.

that said, the creation of the symlink is the expected behavior today. one workaround would be to change directories into your test-commonjs project and run npm pack, then install your dependency from the tarball that's generated rather than the directory. the downside to this is if you make changes to your dependency, you'll have to npm pack it and install it again.jsj

edit:
a shortcut for this is to run npm i $(npm pack ../test-commonjs)

[RobertBeilich]

eslint is not able to follow the symlink? that seems strange.

the symlink is not the problem. the problem is that eslint (apparently) expects the plugins to be directly in node_modules (like ansi-font in the above example).

dependency tree for better clarification:

project
└── my_plugin
          └── eslint-plugin-react

now the node_modules of project need to include my_plugin and eslint-plugin-react for eslint to work. With npm install from remote that is what happens, if npm install from local eslint-plugin-react is missing.

that said, the creation of the symlink is the expected behavior today. one workaround would be to change directories into your test-commonjs project and run npm pack, then install your dependency from the tarball that's generated rather than the directory. the downside to this is if you make changes to your dependency, you'll have to npm pack it and install it again.

npm pack works as a workaround, thanks 👍

I still would expect npm install to behave exactly the same for both remote and local.
And if this is a no-fix, it would at least be great to have it documented somewhere.

[nlf]

With npm install from remote that is what happens, if npm install from local eslint-plugin-react is missing.

this is part of the behavior of linking a directory, we don't actually install that package and its dependencies, instead we only create a symlink and leave the already existing node_modules in place. that's why you end up with "my_plugin" and "eslint-plugin-react" not being at the same depth in node_modules.

you're right that we should document this more clearly, creating links when installing a directory is definitely a change in behavior with npm 7.

[ljharb]

(In general, when linking, all peer deps must also be linked, eslint included - this requirement, sadly, isn't new)

[nlf]

keeping open to track ensuring that the documentation is clear about this behavior, and we document the workaround.

[target-san]

Hello,
This is still reproduced on v8.1.1, and documentation is misleading here:

• npm install :

Install the package in the directory as a symlink in the current project. Its dependencies will be installed before it's linked. If <folder> sits inside the root of your project, its dependencies may be hoisted to the top-level node_modules as they would for other types of dependencies.

Neither installing nor hoisting happens.

[wraithgar]

This was the same issue as #4428, and the docs have been updated to remove this incorrect info.