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

[fischeversenker]

Is there an existing issue for this?

• I have searched the existing issues

Potentially related issues:

• [BUG] npm install fails to resolve compatible peerDependencies requirements #4104: almost the same but involves multiple direct dependencies
• [BUG] peerDependency package version doesn't resolve correctly  #4442: similar but not only involves peer dependencies

This issue exists in the latest npm version

• 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/ng-aquila@16.10.0 has a peer dependency to @angular/core@^16.0.0. This resolves to the latest version in the allowed range: @angular/core@16.2.12
2. the package @aposin/ng-aquila@16.10.0 also has a peer dependency to @angular/cdk@^16.0.0. This resolves to the latest version in the given range: @angular/cdk@16.2.12
3. the package @angular/cdk@16.2.12 has a peer dependency to @angular/common@^16.0.0 || ^17.0.0. This resolves to the latest version in that range: @angular/common@17.0.4
4. the package @angular/common@17.0.4 has a peer dependency to @angular/core@17.0.4 which conflicts with @angular/core@16.2.12 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/core@16.2.12 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/ng-aquila@16.10.0
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/ng-aquila@16.10.0
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.

[plalx]

This indeed is a major dealbreaker. It prevents to create starter-like packages that abstracts away the required dependencies. For instance, I was trying to create an angular-base package for my organization that would manage all dependencies and where we'd only need to add a dependency on that base package in our apps (akin to Spring Boot starters), but I'm running into this issue.

The only way I've manage to make it work is to use custom install processes that would add shadow transitive dependencies in the consumer app and remove them after the npm install process ran. It works and it's better than having to define 30+ dependencies directly in all apps, but we're fighting the ecosystem...

[ljharb]

@plalx the way to abstract away dependencies is to put them in dependencies. If it needs to be in peerDependencies, it can not and must not be abstracted away, because it's a prerequisite of your package that your consumer must be aware of.

[plalx]

@plalx the way to abstract away dependencies is to put them in dependencies. If it needs to be in peerDependencies, it can not and must not be abstracted away, because it's a prerequisite of your package that your consumer must be aware of.

@ljharb I've faced the same problem whether using peerDependencies or dependencies in the "starter" package. npm install only resolved dependencies without conflict when adding all dependencies directly in the consumer application.

I had a dep onngx-mask@^16 in the consumer app as well as a dep on angular-base (which declared Angular 20 dependencies).

When running npm install it would resolve some Angular 21 packages because ngx-mask specifies Angular peer ranges as >=14 and then fail because my "starter" package would require Angular 20 (either in dependencies or peerDependencies).