[BUG] ERESOLVE error because only latest version in peer dependency range is respected in dep resolution

[fischeversenker]

Is there an existing issue for this?

• [X] I have searched the existing issues

Potentially related issues:

• #4104: almost the same but involves multiple direct dependencies
• #4442: similar but not only involves peer dependencies

This issue exists in the latest npm version

• [X] I am using the latest npm

Current Behavior

I'm installing a package with peer dependencies. These peer dependencies are given in ranges. During the dependency resolution only the latest version of each of these ranges is respected, so compatible non-latest versions that would satisfy the given ranges are dismissed.

---

An example:

This bug report is based on a package called @aposin/ng-aquila in version 16.10.0, but this is reproducible with a lot of other packages as well. The problem is always the same.

Deciphered error message:

1. the package @aposin/[email protected] has a peer dependency to @angular/core@^16.0.0. This resolves to the latest version in the allowed range: @angular/[email protected]
2. the package @aposin/[email protected] also has a peer dependency to @angular/cdk@^16.0.0. This resolves to the latest version in the given range: @angular/[email protected]
3. the package @angular/[email protected] has a peer dependency to @angular/common@^16.0.0 || ^17.0.0. This resolves to the latest version in that range: @angular/[email protected]
4. the package @angular/[email protected] has a peer dependency to @angular/[email protected] which conflicts with @angular/[email protected] that was found in step 1, leading to an ERESOLVE error

Expected Behavior

The dependency @angular/common@^16.0.0 || ^17.0.0 should have been resolved to a version that specifies a peer dependency that is compatible with the other found peer dependencies. npm only looks at the latest version in that range and dismisses the matching versions that would satisfy all specified dependency ranges. In this case, installing version 16.x for the range @angular/common@^16.0.0 || ^17.0.0 would have led to @angular/[email protected] which satisfies all dependency ranges.

Steps To Reproduce

1. Create a new folder and run npm init -y to create a new package.json without any dependencies
2. Run npm install @aposin/[email protected]
3. See the ERESOLVE error

Environment

• npm: 10.2.3
• Node.js: 21.2.0
• OS Name: Ubuntu 20.04
• System Model Name:
• npm config:

; node bin location = </some/path>
; node version = v21.2.0
; npm local prefix = </some/path>
; npm version = 10.2.3
; cwd = </some/path>
; HOME = </some/path>
; Run `npm config ls -l` to show all defaults.

[ljharb]

Sometimes this can’t be solved programmatically; you need to explicitly depend on v16 in the root project (as you should be explicitly depending on every peer dep in the root project)

[fischeversenker]

Thanks for your response, @ljharb.

you should be explicitly depending on every peer dep in the root project

I'm surprised to read this. I was hoping that because npm now automatically installs peer dependencies we don't need to do that anymore. Reading the initial RFC, I have to admit, though, that it sounds like it was never the goal to relieve the users from this manual duty.

So it's still recommended to manually collect and state all peer dependencies in the root package.json. The main benefit that we get from the automatic peer dependency installation is to receive a warning if we have the wrong peer dependency installed. Is that right?

[ljharb]

It’s impossible for any program to automatically resolve every issue; it’s an NP hard problem. You as the human have to do something.

yes, that’s correct.

[fischeversenker]

I had a look at this again today and to me, this is still surprising. Especially looking at the reproduction steps that I provided:

1. Create a new folder and run npm init -y to create a new package.json without any dependencies
2. Run npm install @aposin/[email protected]
3. See the ERESOLVE error

So as users, we need to be aware that there are packages out there that you can't simply install on their own. You need to first figure out what their peer dependencies are and install these first.

It’s impossible for any program to automatically resolve every issue; it’s an NP hard problem. You as the human have to do something.

I understand that solving this properly is an NP-hard problem. However, I can imagine that resolving the dependency tree only one more level will likely solve a lot of these problems. Would that be something you could consider?

[icholy]

Sometimes this can’t be solved programmatically; you need to explicitly depend on v16 in the root project (as you should be explicitly depending on every peer dep in the root project)

Sure, but the majority of common cases (including the provided example) are solvable.