[BUG] npm stuck during workspace installation

[Eomm]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Running the installation of modules that has a mismatch peerDependancy lead to an infinite installation within the process stuck at 100% CPU

The origin of this issue comes from solving the installation issue on this project, where I used --legacy-peer-deps to complete the installation:
https://github.com/nearform/titus/runs/3967425473?check_suite_focus=true

titus@1.0.0 /Users/mspigolon/workspace/titus
├─┬ titus-backend@1.0.0-alpha.1 -> ./packages/titus-backend
│ └─┬ @nearform/brokeneck-fastify@1.0.0-spinal.8
│   └─┬ @nearform/brokeneck-html@1.0.0-spinal.8
│     └─┬ react-scripts@4.0.1
│       └── babel-loader@8.1.0
└─┬ titus-frontend@1.0.0-alpha.1 -> ./packages/titus-frontend
  ├─┬ @storybook/addon-docs@6.3.12
  │ ├─┬ @storybook/builder-webpack4@6.3.12
  │ │ └── babel-loader@8.2.3
  │ └─┬ @storybook/core@6.3.12
  │   └─┬ @storybook/core-server@6.3.12
  │     └─┬ @storybook/manager-webpack4@6.3.12
  │       └── babel-loader@8.2.3 deduped
  ├─┬ @storybook/react@6.3.12
  │ └─┬ @storybook/core-common@6.3.12
  │   └── babel-loader@8.2.3 deduped
  └─┬ react-scripts@4.0.3
    └── babel-loader@8.1.0

The titus-frontend loads:

/titus/node_modules/babel-loader

instead of:

/titus/node_modules/react-scripts/node_modules/babel-loader

Maybe it is related to:
#3208

Expected Behavior

The installation should complete

Steps To Reproduce

mkdir npm-stuck
cd npm-stuck
npm init --yes
npm init -w pkg-a --yes
npm install react-scripts -w pkg-a
npm install @storybook/react -D -w pkg-a

Environment

Github action (all OSs and npm 8.1.0 and 7.24.2)
https://github.com/Eomm/npm-stuck/actions/runs/1371673160

Note the windows jobs are green, but it shows the out of memory stacktrace.

[lukekarrys]

Thanks for the report @Eomm! I've confirmed this is an infinite loop caused only when installing inside a workspace. This also looks similar to #3385 which was fixed in Arborist, and I confirmed that case is no longer reproducible. I was able to run npm install @storybook/react -D -w pkg-a --loglevel silly and found this chunk of logs as the one that gets stuck repeating:

npm sill placeDep ROOT @babel/preset-flow@7.14.5 OK for: @storybook/react@6.3.12 want: ^7.12.1
npm sill placeDep ROOT @storybook/addons@6.3.12 OK for: @storybook/react@6.3.12 want: 6.3.12
npm sill placeDep ROOT @storybook/core@6.3.12 OK for: @storybook/react@6.3.12 want: 6.3.12
npm sill placeDep ROOT @storybook/core-common@6.3.12 OK for: @storybook/react@6.3.12 want: 6.3.12
npm sill placeDep ROOT @storybook/node-logger@6.3.12 OK for: @storybook/react@6.3.12 want: 6.3.12
npm sill placeDep ROOT @storybook/react-docgen-typescript-plugin@1.0.2-canary.253f8c1.0 OK for: @storybook/react@6.3.12 want: 1.0.2-canary.253f8c1.0
npm sill placeDep ROOT @storybook/semver@7.3.2 OK for: @storybook/react@6.3.12 want: ^7.3.2
npm sill placeDep ROOT @types/webpack-env@1.16.3 OK for: @storybook/react@6.3.12 want: ^1.16.0
npm sill placeDep ROOT babel-plugin-add-react-displayname@0.0.5 OK for: @storybook/react@6.3.12 want: ^0.0.5
npm sill placeDep ROOT babel-plugin-react-docgen@4.2.1 OK for: @storybook/react@6.3.12 want: ^4.2.1
npm sill placeDep ROOT global@4.4.0 OK for: @storybook/react@6.3.12 want: ^4.4.0
npm sill placeDep ROOT ts-dedent@2.2.0 OK for: @storybook/react@6.3.12 want: ^2.0.0
npm timing idealTree:node_modules/@storybook/react Completed in 17ms
npm sill placeDep node_modules/@babel/preset-flow @babel/plugin-transform-flow-strip-types@7.14.5 OK for: @babel/preset-flow@7.14.5 want: ^7.14.5
npm timing idealTree:node_modules/@babel/preset-flow Completed in 1ms
npm sill placeDep ROOT @storybook/api@6.3.12 OK for: @storybook/addons@6.3.12 want: 6.3.12
npm sill placeDep ROOT @storybook/channels@6.3.12 OK for: @storybook/addons@6.3.12 want: 6.3.12
npm sill placeDep ROOT @storybook/client-logger@6.3.12 OK for: @storybook/addons@6.3.12 want: 6.3.12
npm sill placeDep ROOT @storybook/core-events@6.3.12 OK for: @storybook/addons@6.3.12 want: 6.3.12
npm sill placeDep ROOT @storybook/router@6.3.12 OK for: @storybook/addons@6.3.12 want: 6.3.12
npm sill placeDep ROOT @storybook/theming@6.3.12 OK for: @storybook/addons@6.3.12 want: 6.3.12
npm timing idealTree:node_modules/@storybook/addons Completed in 12ms
npm sill placeDep ROOT @reach/router@1.3.4 OK for: @storybook/api@6.3.12 want: ^1.3.4
npm sill placeDep ROOT react@16.14.0 REPLACE for: @reach/router@1.3.4 want: 15.x || 16.x || 16.4.0-alpha.0911da3
npm sill placeDep ROOT react-dom@16.14.0 OK for: @reach/router@1.3.4 want: 15.x || 16.x || 16.4.0-alpha.0911da3
npm sill placeDep ROOT react@16.14.0 OK for: react-dom@16.14.0 want: ^16.14.0
npm sill placeDep ROOT @storybook/csf@0.0.1 OK for: @storybook/api@6.3.12 want: 0.0.1
npm sill placeDep ROOT @types/reach__router@1.3.9 OK for: @storybook/api@6.3.12 want: ^1.3.7
npm sill placeDep ROOT memoizerific@1.11.3 OK for: @storybook/api@6.3.12 want: ^1.11.3
npm sill placeDep ROOT qs@6.10.1 OK for: @storybook/api@6.3.12 want: ^6.10.0
npm sill placeDep ROOT store2@2.12.0 OK for: @storybook/api@6.3.12 want: ^2.12.0
npm sill placeDep ROOT telejson@5.3.3 OK for: @storybook/api@6.3.12 want: ^5.3.2
npm sill timing Tried to end timer that doesn't exist: idealTree:#root
npm sill placeDep ROOT @storybook/react@6.3.12 OK for: pkg-a@1.0.0 want: *
npm sill placeDep ROOT react-dom@17.0.2 OK for: @storybook/react@6.3.12 want: ^16.8.0 || ^17.0.0
npm sill placeDep ROOT react@17.0.2 REPLACE for: react-dom@17.0.2 want: 17.0.2
npm timing idealTree:pkg-a Completed in 3ms

[simoneb]

It's also worth mentioning that the same command, run on another OS (Windows, I can provide more details if needed), does not exhibit the same behavior, meaning that it does not hang indefinitely. I can't say whether it's the OS making the real difference or other circumstance, though.

[lukekarrys]

@simoneb That's interesting. I have this issue reproduced with a failing test case (npm/arborist#343) that I'm working to fix this week. Our CI will run it across all OS we support so that should show us if we have any different platform behavior.

If you have a repo with a package-lock that hangs on Windows that would be very helpful.

[simoneb]

I do not have such a repo because the command that @Eomm mentioned in the issue when run on my Windows machine does not hang, although it does show some slowdown, but eventually comes to a successful end.

[lukekarrys]

does not exhibit the same behavior, meaning that it does not hang indefinitely.

I'm sorry, I misread your previous comment. 🤦 I will poke around at the eventual fix and see if I can find any differences between platforms. Thanks for the info!

[Eomm]

Could some ~/.npmrc settings change the installation flow?

[lukekarrys]

Yes, the most likely being legacy-peer-deps. You can run npm config ls in your project directory to see what config items are being applied from the various .npmrc files in your environment.

[lukekarrys]

@simoneb @Eomm This should be fixed in 8.1.3 released yesterday. If you're still seeing any weirdness it would be helpful to see the package.json, package-lock.json, output with the --loglevel silly flag (which won't get saved to a file if the process never completes), and the output from npm config ls.

[Eomm]

Yes, it is fixed: https://github.com/Eomm/npm-stuck/runs/4130014056?check_suite_focus=true

Will this fix be backported to v7 as well?
The 7.24.2 has the issue too

Thank you