[BUG] npm install <folder> doesn't install the dependencies of that package if it is not a subdir of itself.

[jcompagner]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

let say i have this:

c:\adir\mymainpackagedir

in that dir i have my main package that i am developing.

i want to include other packages also but some of them are local

lets say i have the same other package copies twice:

c:\adir\mymainpackagedir\myotherpackage

c:\adir\myotherpackage

so its exactly the same content

that other package has a (peer)dependency that also needs to be installed.

why i do in the dir: c:\adir\mymainpackagedir

npm install .\myotherpackage

it installs that package and the other dependency (i see 2 installed and with "npm ls" i see them)

but when i do instead:

npm install ..\myotherpackage

only the main package is installed not the dependency of that package.

why is that different?

Expected Behavior

that no matter where it the local folder package comes from the dependencies of that local package are all installed.

Steps To Reproduce

reproduce.zip

unzip the reproduce.zip

go to the "main" folder

first do

npm install ..\pckg\

you see it will only install 1 package

npm ls moment
main@1.0 C:\temp\main
`-- (empty)

then uninstall it:

npm uninstall pckg

and then install the sub child folder:

npm install .\pckg\

you see it installs 2 packages and:

npm ls moment
main@1.0 C:\temp\main
-- pckg@1.0 -> C:\temp\main\pckg -- moment@2.29.1

reports moment

Environment

• OS: windows
• Node: v16.2.0
• npm: 7.14

[nlf]

this is the intended behavior, npm install ../dir doesn't do a full installation of the package in the directory dir, it creates a link to it which does not install its dependencies. if you want to install the contents of a directory as though it were a package from the registry instead of creating a link, as of today you would need to use npm pack while in the dir directory, and then install the resulting tarball instead of the directory.

[jcompagner]

Then you need to tell me what the difference is between

npm install ./dir

or

npm install ../dir

why is there a difference between those 2?

also will you then adjust the documentation?

https://docs.npmjs.com/cli/v7/commands/npm-install

"
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 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.
"

because that second sentence is then plain wrong.

[mdkrieg]

I've run into this as well, why is this the intended function? I was trying to test whether a project I had just split up would resolve a common dependency correctly and had to push to github before it worked correctly. Why would the folder install not resolve dependecies like all the other methods? Using npm pack unfortunately doesn't offer the same flexibility as using the folder install.

Others have been complaining about this too:
npm/npm#16870
npm/npm#13734

The docs certainly seem to say that this should work:

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.

[dmaevsky]

+1 This is very confusing and should NOT be the "intended behavior". Makes the development of closely related packages a total nightmare :/

[jcompagner]

i also still don't get why this difference must be there, it seems that you really need to program this out to do different things..
instead of just handling a npm install the same for everything, that it just installs exactly the same as npm install packagename. All installs should just be handles the same no matter where it comes from.

[adamlacoste]

It would be helpful to at least have a flag for install and ci (e.g. --recursive) to override the default behavior and install for ALL file dependencies. I agree with the others who think the intended behavior is counterintuitive, but I'd be satisfied with a workaround that doesn't require me to write special handling for some file dependencies depending on where they are relative to the package.json in question.

[LoboMetalurgico]

+1 I'm developing a public lib and, in parallel, an application that uses it (both in typescript). It is extremely annoying and complex to have to run "npm run build", "npm pack", "npm install", "npm run build" and finally "npm start"/"npm test" for every small correction and/or feature implemented. This slows down the development of applications like this by a lot, and based on the other comments, certainly other people agree with me.

[ansraliant]

Any idea why this is closed?

This is still the default behavior.

Well, they changed the docs:

If sits outside the root of your project, npm will not install the package dependencies in the directory , but it will create a symlink to

So, if the project is outside your root, it is linked, but it's dependencies not installed.

[Yehonal]

With Yarn this works, and on NPM has been broken since forever

Another reason to migrate

[Mwni]

@Yehonal Can confirm yarn install does exactly what you would expect from npm install when dealing with local dependencies.

[geryogam]

@nlf Would you care to reopen this issue or explain the benefit of the current behavior to the community?

[BalmungSan]

We are in a similar situation to this:

developing a public lib and, in parallel, an application that uses it (both in typescript)
The reason we have the application in place is to validate that the library does what we want before publishing a new version.

npm install not installing the local dependencies, does not only makes our local development experience worse, but also implied introducing drastic changes to our shared GithubActions infrastructure in order to support custom installation scripts.