Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--install-strategy=nested still hoists workspace packages #6537

Open
2 tasks done
pcone opened this issue Jun 8, 2023 · 6 comments
Open
2 tasks done

--install-strategy=nested still hoists workspace packages #6537

pcone opened this issue Jun 8, 2023 · 6 comments
Labels
Bug thing that needs fixing Needs Triage needs review for next steps Release 9.x work is associated with a specific npm 9 release

Comments

@pcone
Copy link

pcone commented Jun 8, 2023

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

Currently, running npm install at the root of a monorepo using npm workspaces with the '--install-strategy=nested' flag almost does what I would expect it to do - it puts all the dependencies in separate node_modules folders for each package, but it still puts
the symlinks to the local monorepo packages at the root.

Expected Behavior

I would expect the symlinks to the monorepo packages to be inserted into the nested node_modules folders rather than the root (and only for the packages that depend on them).

I also noticed that the --omit=dev flag seems to not work in this use case - note in the linked repro repo running 'npm install --install-strategy=nested --omit=dev' still results in eslint being added to workspace2's node_modules folder, even though it's only a devDependency. (I can make a separate issue for this if that would be better?)

Note for context: My use case here is a monorepo with multiple node apps in it, each of which needs to be separately bundled into a docker image with only it's dependencies, I don't want to unnecessarily include the dependencies of other packages in the monorepo. The '--install-strategy=nested' flag seems like what I need for my use case, but the current behaviour doesn't quite work.

Steps To Reproduce

  • make sure you have npm 9.7.1
  • clone this repo: https://github.com/pcone/npmissuerepro
  • run 'npm install --install-strategy=nested --omit=dev' at the root
  • note that a node_modules folder is still created at the root
  • note that the nested node_modules folder for workspace1 does not contain a symlink to workspace2, despite it being a dependency
  • note that eslint is still installed, despite being a dev dependency

Environment

  • npm: 9.7.1
  • Node.js: 16.16.0
  • OS Name: Windows 10 22H2
  • npm config:
; "user" config from C:\Users\<redacted>\.npmrc

<redacted internal repo>:_password = (protected)
<redacted internal repo>:email = "not-used@example.com"
<redacted internal repo>:username = <redacted>

; node bin location = C:\Program Files\nodejs\node.exe
; node version = v16.16.0
; npm local prefix = C:\S
; npm version = 9.7.1
; cwd = C:\S\npmrepro
; HOME = C:\Users\<redacted>
; Run `npm config ls -l` to show all defaults.
@pcone pcone added Bug thing that needs fixing Needs Triage needs review for next steps Release 9.x work is associated with a specific npm 9 release labels Jun 8, 2023
@morganney
Copy link

I have experienced the same issue.

@pcone to get around the --omit=dev issue you need npm >= 9.7.2.

Another repo for reproducing: https://github.com/morganney/npm-workspaces

If you run npm install --install-strategy=nested --omit=dev --workspace=foo there will be transitive dependencies for foo's dependencies inside of the root node_modules folder.

I have created a workaround for this shortcoming by running npm run build:foo which effectively moves deps around from the associated node_modules directories.

@rmclaughlin-nelnet
Copy link

rmclaughlin-nelnet commented Aug 14, 2023

I have also experienced this. I have also seen shared dependencies still being hoisted. node-fetch seems to be affected. We have a several dependencies that depend on it and no matter what npm install --install-strategy=nested installs it in the root, not the sub packages. npm install --install-strategy=linked seems to work better, but it is not optimal.

It would be great to see a fix for this.

@iamyobi
Copy link

iamyobi commented Dec 21, 2023

I have the same issue.
npm 9.8.1
node 18.18.2

I removed node_modules

  • node_modules/
  • packages/PACAKGE/node_modules/

and ran install command with install-strategy=nestedoption in package root, It doesn't help.

@requiel20
Copy link

Also affected by this

@r3ps4J
Copy link

r3ps4J commented Apr 30, 2024

Same issue here, npm 10.5.2 on node v20.11.1. I can't used linked either because it breaks the angular compiler.

@benqus
Copy link

benqus commented May 15, 2024

--install-strategy=nested does not work in npm@10.5.2 - I suggest this option to be taken out from the docs or at least mark it as such as it's misleading

hansott added a commit to AikidoSec/firewall-node that referenced this issue Jul 15, 2024
Note: this is configured in .npmrc file but it's different that npm's
install strategy, tried to use npm's workspaces and disable hoisting but
stumbled upon npm/cli#6537
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug thing that needs fixing Needs Triage needs review for next steps Release 9.x work is associated with a specific npm 9 release
Projects
None yet
Development

No branches or pull requests

7 participants