Repository navigation
[BUG] npm does not include prerelease versions when matching with peerDependencies #7303
Description
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
Activity
ljharb commentedon Mar 20, 2024
This is by design. Prereleases are never included unless you use a more explicit prerelease range (like
^4.3.1-0, i believe)pulges commentedon Mar 20, 2024
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 commentedon Mar 20, 2024
If you’re trying to test prereleases, you should use overrides. If a range includes them, all users would get them by default.
wraithgar commentedon Mar 26, 2024
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 commentedon Aug 6, 2024
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