[BUG] `npm install <folder>` while absolute path or parent level ("../") provided

[spamshaker]

Is there an existing issue for this?

• I have searched the existing issues

This issue exists in the latest npm version

• I am using the latest npm

Current Behavior

npm install ../relative-path-to-my-module doesn't resolve the dependencies of the installed module

this happens only when path goes to the directory level up like "my-module-a:file:../my-module-a" or if the path is absolute.

Expected Behavior

the dependencies should be installed in current module

should behave the same way as yarn install command

Steps To Reproduce

1. checkout example git clone https://github.com/spamshaker/npm-bug
2. cd npm-but/my-module-b
3. npm install
4. See react dependency is not installed in my-module-b
   
   react dependency should be resolved and installed in my-module-b

Environment

• npm: 8.3.0
• Node: 16.13.0
• OS: Windows 11
• platform:
• npm config:

; copy and paste output from `npm config ls` here

[nlf]

this is currently intended behavior. when installing a directory outside of the current one, we create a link rather than installing the dependency. when we create links we do not install the dependencies of the linked package.

you can see the docs for this behavior here: https://docs.npmjs.com/cli/v8/commands/npm-install though you'll need to scroll down until you find the heading npm install <folder>

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.

[nlf]

although it occurs to me just now that the docs are worded wrong, and are misleading about this behavior, so i'm reopening this as a note to correct the documentation

[foxxyz]

this is currently intended behavior. when installing a directory outside of the current one, we create a link rather than installing the dependency. when we create links we do not install the dependencies of the linked package.

@nlf is there are a link to a rationale for this change somewhere? And what the suggested workaround is?

Saw this discussed in #2339 also, so far I'm struggling to understand this change - it's certainly causing a lot of annoyances on my own projects (E.G. needing to recurse into each linked local package and manually run npm install)...

[boutell]

So if you use npm install -g ./local-folder, you get a global symlink to your local folder, instead of an actual installation from it, including dependencies, like previous releases? That's a pretty big change.

[manekinekko]

FWIW a fix for the docs has already landed in #4428.

[neodescis]

This behavior makes it almost impossible to consume an angular library that is installed/linked locally if the library has dependencies defined. The only way Angular can consume a locally installed/linked library is with preserveSymlinks enabled. This is because the Angular application will fail to run if there is more than one instance of the Angular framework loaded, which is what happens when preserveSymlinks is disabled. However, enabling the flag means the build will not look at the installed/linked library's node_modules folder, which then means the library's dependency won't be resolved, and the build fails.

Is there any chance the linked library's dependencies could be installed, even with a flag or something?