[BUG] npm workspaces wrong dependancies tree

[Eomm]

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

The dependencies installation order in an npm workspaces project, build a wrong node_modules/ tree compared to the npm ls one.

Installing jest@latest (v27) the module is installed into:

root/node_modules

Then, installing react-scripts@latest (v4) into another workspace's package the resulting tree for the sub dependency babel-jest:

├─┬ [email protected] -> ./pkg-a
│ └─┬ [email protected]
│   └─┬ @jest/[email protected]
│     └─┬ [email protected]
│       └── [email protected]
└─┬ [email protected] -> ./pkg-b
  └─┬ [email protected]
    ├── [email protected]
    └─┬ [email protected]
      └─┬ [email protected]
        └─┬ [email protected]
          └── [email protected] deduped

But the output is the following:

The [email protected] module is installed into the root/node_modules/react-scripts/node_modules/babel-jest folder.

It triggers a loading error because the react-scripts module into pkg-b loads the:

root/node_modules/babel-jest v27

Instead of

root/node_modules/react-scripts/node_modules/babel-jest v26

Expected Behavior

I would expect a root/pkg-b/node_modules/babel-jest installation and not into the root/node_modules/react-scripts/node_modules/babel-jest.

Steps To Reproduce

npm init --yes
npm init -w pkg-a --yes
npm init -w pkg-b --yes
npm install jest@27 -D -w pkg-a
npm install react-scripts@4 -w pkg-b
npm set-script test "react-scripts test" -w pkg-b
npm ls babel-jest
npm test -w pkg-b

Environment

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

[kirrg001]

I am running into the same (hopefully similar) problem. We've switched to NPM workspaces and suddenly our tests are failing because of (I think) a wrong dependency requirement.

Install these dependencies into a package A as a dev dependency:

devDependencies:
  "@opentelemetry/api": "1.0.3",
  "@opentelemetry/instrumentation": "0.24.0",
  "@opentelemetry/instrumentation-http": "0.24.0",

@opentelemetry/api get's installed in the package A node_modules folder.
But the others are NOT. I guess NPM installs the dependency into the package A node_modules because there are two versions of @opentelemetry/api installed. Continue reading. For @opentelemetry/instrumentation there is only one version tagged in the locked file.

Install @google-cloud/pubsub@^2.12.0 as dev dependency in root package.json.
@opentelemetry/[email protected] get's installed in root node_modules, because it's a sub dependency of @google-cloud/pubsub@^2.12.0.

Now @opentelemetry/instrumentation (which is installed in the root folder) requires the wrong api version 0.18.x (which is also installed on root). Although @opentelemetry/instrumentation is using peerDependency

  "peerDependencies": {
    "@opentelemetry/api": "^1.0.1"
  },

I can confirm: This issue is present on latest 8 and 7.24.2 too!

As soon as I force (which is not a workaround!) having multiple versions installed of other packages (@opentelemetry/instrumentation etc) in the package A node_modules folder, the test passes again and require will use the correct version. I then have 0.24 in root folder and 0.26 in workspace folder.

Are there known (none hacky!) workarounds?
It feels like this is a design problem or better said there is a bigger underlying issue with workspaces?

Thanks a lot!

[kirrg001]

Looks related to #2989?

[Eomm]

Note that the --legacy-bundling flag seems to work:

npm install jest@27 -D -w pkg-a --legacy-bundling
npm install react-scripts@4 -w pkg-b --legacy-bundling

[nlf]

@Eomm this is a bug in react-scripts that was fixed as part of this pull request facebook/create-react-app#11474 so the good news is, if you're able to update your react-scripts dependency you shouldn't have this issue any more. the root cause was hard coded assumptions about how npm would hoist dependencies. since this was their bug and not ours, i'm going to go ahead and close this.

@kirrg001 i'm not able to reproduce your issue, can you open a new issue and include step-by-step instructions to reproduce the problem you're seeing? that will help a lot with our investigation. thanks!

[Eomm]

Since the project I was working on run lerna successfully, does it mean that if a user wants to use npm workspaces, the user must be aware that it may need to update your dependencies as well?