[BUG] npm does not include prerelease versions when matching with peerDependencies

[pulges]

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

In a private library I have

"peerDependencies": {
    "my-package": ">=4"
}

and I get "Could not resolve dependency" error when trying to install snapshot versions of library llike

4.3.1-master.1710852533570

The issue has been reported before (#4958) but closed without actually explaining why npm has to diverge from semver specifications and have such undocumented side-effect.

The support for pre-release versions in peerDependencies is really required, when multiple libraries are being developed in conjunction to modularize development environment. Currently solutions to use incorrect "*" as peerDependency criteria or overrides, are very cumbersome to use between multiple developers and can also result in these lines being forgotten and leaking into production code.

Expected Behavior

In peerDependencies conditions should match also prerelease versions.

Steps To Reproduce

No response

Environment

• npm: 10.5.0
• Node.js: v20.11.0
• OS Name: Ubuntu
• System Model Name: 23.10

[ljharb]

This is by design. Prereleases are never included unless you use a more explicit prerelease range (like ^4.3.1-0, i believe)

[pulges]

I do understand, why npm should not pick a prerelease package automatically during installation. But throwing an error message for handpicked prerelease package that actually matches, seems like a totally different issue and I still do not quite underatand the reasons behind this design choice.

[ljharb]

If you’re trying to test prereleases, you should use overrides. If a range includes them, all users would get them by default.

[wraithgar]

Yes, this is by design. Pre-releases have to be explicitly asked for to be installed. By definition that version has not been released. It would be inappropriate for users to get it before it's ready.

Folks have solved the issue of testing multiple packages in prerelease mode with overrides, npm link, or workspaces. It is admittedly a hard problem to solve, but breaking existing installations by including prereleases is not the solution.

[Sophos-Elias-Vasylenko]

Yes, this is by design. Pre-releases have to be explicitly asked for to be installed. By definition that version has not been released. It would be inappropriate for users to get it before it's ready.

FWIW I believe the argument here is that they are being explicitly asked to be installed in this case, and that users would categorically not be exposed to pre-releases by default in this scenario.

A peer dependency directly listed on the current package should still resolve to non-pre-release versions according to the current behaviour. I think what is being suggested is that a transitive peer dependency can be satisfied by a pre-release version iff a pre-release version is explicitly requested by the host app.

Others arriving here should see the RFC here for more discussion npm/rfcs#397

I'm not asking to reopen the ticket, and I realise most of the people here are involved in the RFC discussion and aware of these arguments :). I'm mainly just commenting for the benefit of future searches as this was one of the first tickets I came across when searching for answers about this. Hope that's okay.

Cheers