[BUG] Multiple related packages install fail due to wrong peerDependencies resolution

[cyrilletuzi]

Current Behavior:

When having multiple packages relying on each others having the exact same version, trying to update them all via npm install fails when there is another package which loosely rely on them via "peerDependencies": "^x.x.x", due to npm7 erroneous resolution.

Real world example: Angular core packages are supposed to be installed with the exact same version, so for example @angular/common@11.2.9 has "peerDependencies": { "angular/core": "11.2.9" } (note the exact version).

Until now everything is fine. You can update all versions to 11.2.10 in package.json, run npm install and it works.

But now add another package which relies on one of the core packages, for example @angular-devkit/build-angular@11.2.9 has a "peerDependencies": { "@angular/compiler-cli": "^11.0.0 || ^12.0.0-next" }.

Now if you update all versions to 11.2.10 in package.json and run npm install, it fails.

Expected Behavior:

npm install should work, as versions are correct and peerDependencies are respected.

Steps To Reproduce:

Working:

1. mkdir npmissue
2. cd npmissue
3. npm init -y
4. npm install @angular/common@11.2.9 @angular/compiler@11.2.9 @angular/core@11.2.9 @angular/platform-browser@11.2.9 @angular/platform-browser-dynamic@11.2.9 -E
5. npm install @angular/compiler-cli@11.2.9 -D -E
6. Search/replace 11.2.9 > 11.2.10 in package.json
7. npm install: OK

Failing:

1. Previous steps from 1 to 5 (included)
2. npm install @angular-devkit/build-angular@11 -D -E
3. Search/replace 11.2.9 > 11.2.10 in package.json
4. npm install: fails with peerDependencies errors

npm log

Found: @angular/common@11.2.9
node_modules/@angular/common
  @angular/common@"11.2.10" from the root project
  peer @angular/common@"11.2.9" from @angular/platform-browser@11.2.9
  node_modules/@angular/platform-browser
    @angular/platform-browser@"11.2.10" from the root project
    peer @angular/platform-browser@"11.2.9" from @angular/platform-browser-dynamic@11.2.9
    node_modules/@angular/platform-browser-dynamic
      @angular/platform-browser-dynamic@"11.2.10" from the root project
  peer @angular/common@"11.2.9" from @angular/platform-browser-dynamic@11.2.9
  node_modules/@angular/platform-browser-dynamic
    @angular/platform-browser-dynamic@"11.2.10" from the root project

Could not resolve dependency:
@angular/common@"11.2.10" from the root project

Conflicting peer dependency: @angular/core@11.2.10
node_modules/@angular/core
  peer @angular/core@"11.2.10" from @angular/common@11.2.10
  node_modules/@angular/common
    @angular/common@"11.2.10" from the root project

Fix the upstream dependency conflict, or retry
this command with --force, or --legacy-peer-deps
to accept an incorrect (and potentially broken) dependency resolution.

Environment:

• OS: macOS 11.2.3
• Node: 14.16.1
• npm: 7.9.0

Additional information:

This issue was raised because it causes issues in automatic dependencies update tools like Renovate, which are doing exactly what I described: updating the package.json and then doing a npm install.

See renovatebot/renovate#9561 for the Renovate issue, and cyrilletuzi/angular-async-local-storage#628 for a real world example, with npm logs.

Additional debug info:

Doing rm -rf node_modules && rm package-lock.json, then npm install works without errors or warnings.

Or doing npm install --force, then npm install has no more errors.

Meaning the peerDependencies are indeed respected and it should work in the first place. Seems like the presence of package-lock.json and/or node_modules results in an issue in correct dependencies resolution.

[rarkins]

Based on my debugging of this issue for Renovate, I found:

• For the case that fails, deleting both package-lock.json and node_modules then running npm install works fine
• If either package-lock.json or node_modules are present then npm install fails
• npm install --force works, and after that so too does npm install

[bwateratmsft]

I think I'm seeing roughly this same behavior with eslint not installing @eslint/eslintrc, and also issues with umd-compat-loader.

[AlanSl]

Here's another example, installing react-navigation, in a workspace named app:

npm ERR! While resolving: app@0.0.1
npm ERR! Found: react@17.0.2
npm ERR! node_modules/react
npm ERR!   peer react@"*" from react-navigation@4.4.4
npm ERR!   node_modules/react-navigation
npm ERR!     react-navigation@"*" from the root project
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer react@"17.0.1" from react-native@0.64.0
npm ERR! node_modules/react-native
npm ERR!   peer react-native@"*" from react-navigation@4.4.4
npm ERR!   node_modules/react-navigation
npm ERR!     react-navigation@"*" from the root project

The exact same issue happens with many other packages in the React Native ecosystem - for example callstack/react-native-paper#2603. What's going on here as I read it:

• react-navigation (and others) has permissive peer deps react@"*" and react-native@"*"
• Latest react release is 17.0.2
• Latest react-native release is 0.64.0 which has a strict peer dep react@"17.0.1

NPM sees this as a conflict and crashes. I think this is a bug because all deps can be satisfied with 17.0.1 - if someone puts * in their peer dep specification, shouldn't crash on having to downgrade one patch release from the very latest.

Looks like the open PR npm/arborist#266 should solve this, thanks.

[leonheess]

why is this closed? It's still active in 8.11.0

[tonivj5]

why is this closed? It's still active in 8.11.0

@leonheess follow this issue #3666