[BUG] "npm install" for workspaces is not consistent

[WolfspiritM]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

I have a repository with many small projects. At the moment developers work in different projects and "npm install" directly in there. I want to link these projects together with workspaces now.

My naive approach was to create a package json in the root and "npm install" there. This kind of works however it wasn't using the lock files in the projects and created a new lock file so a build in the projects failed as one of the dependency seems to break it. I've fixed that dependency but that made me worry about how reliable the locking in workspaces is.

My next idea was to remove the lock file from the projects and just use the global lock file as that seem to be the way it is intended. How the lock file works in workspaces is not really documented anywhere.

However as there are multiple developers I don't seem to find a way to prevent developers to "npm install" in the projects (maybe out of habbit) causing the "global" package-lock to stay untouched and a CI/CD run to fail or create unexpected results.

Expected Behavior

I expect that if I use "npm install" in the projects that are member of a root projects it is the same as doing "npm install -w project" from the root and produce the same output. If the project is part of multiple workspaces it should "forward" the install call to the root project and not create independend lock files. Right now it also seems to create different node_modules depending of calling "npm install" within the module or "npm install" from the root.

With the current implementation I'd also expect the documentation (https://docs.npmjs.com/cli/v7/using-npm/workspaces) to mention that "npm install" should not be called within the child packages but from the root and also explain how to make sure there are no unexpected lock files created.

Steps To Reproduce

1. Create a package.json

{
  "workspaces": [
    "mod"
  ]
}

2. Create a folder "mod" within that project with a package.json

{
  "name": "mod",
  "dependencies": {
    "lodash": "^3.9.3"
  }
}

3. Run "npm install"

This creates a "node_modules" folder in the root and a package-lock.json and mod doesn't have any "node_modules" which is as expected.

4. Call "npm install -w mod". Nothing changes (this behaviour is expected)
5. "cd mod"
6. Call "npm install"

This time we will end up with a "package-lock.json" and a node_modules folder inside the mod folder. This is not expected as "npm install" from the mod directory should be consistent with "npm install -w mod" as the documentation says:

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

Enable running a command in the context of the configured workspaces of the current project.

7. Update lodash version in the "mod" project to ^4.17.20 and call "npm install" from that project again
   Now the package-locks are completly out of sync. While a "npm install" from the package will install version 4 a global npm install will still install version 3...this is really unexpected.

Environment

• OS: Windows 10
• Node: v16.3.0
• npm: 7.16.0

[mtone]

I expect that if I use "npm install" in the projects that are member of a root projects it is the same as doing "npm install -w project"

I'd also expect the documentation (https://docs.npmjs.com/cli/v7/using-npm/workspaces) to mention that "npm install" should not be called within the child packages

I feel these 2 statements contradict each other. If running it from a child package behaves consistently with running it from the root with -w, then it should be considered perfectly acceptable to run "npm install" from a child package. Yarn works this way and is desirable and intuitive to me.

What brought me here is a package that generously auto-runs "npm install" as part of a build script, and it breaks due to not being workspace-aware. As a workaround, I put a "npm.bat" in the child package that redirects the command to the root...

[WolfspiritM]

I feel these 2 statements contradict each other. If running it from a child package behaves consistently with running it from the root with -w, then it should be considered perfectly acceptable to run "npm install" from a child package. Yarn works this way and is desirable and intuitive to me.

Yes I agree. If npm install from a child package works the same as from the root then it's totally fine. But with the current way it is done then I'd expect it to be mentioned somewhere in the docs that you should not run npm install in the child project. I have changed that part to make it more clear.

[gavinsharp]

See also: #2546

[ruyadorno]

Support for this should have landed in npm@8.5.0