You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[ENHANCEMENT] Allow * prerelease versions for * version ranges. #736
I came across the behaviour described in this issue: #510
The behaviour is that 1.x.x-whatever ranges as parsed, but the prerelease version is just ignored. I agree with the comment on that issue that something like 1.0.*-rc doesn't really make much sense and isn't terribly useful. Presumably the resolution to this problem is one of the following:
Fail to parse these ranges
Allow these ranges, and ONLY match versions with the exact prerelease
Allow these ranges and allow 1.x.x OR versions with the exact prerelease
However I do think that something like 1.*.*-* could serve a genuine purpose. Currently this version range does not parse.
Expected Behavior
For context, I was trying to find work-arounds for npm/rfcs#397. This is an RFC to update NPM behaviour to make development of peer dependencies more convenient, so that we can satisfy a peer dependency range with a prerelease version if the host app explicitly specifies one.
In lieu of a happy resolution to the RFC, it would be useful to allow a peer dependency to signal that it is intended to accept pre-releases at the discretion of the importing package. And a 1.*.*-* style version range could satisfy this purpose.
Steps To Reproduce
In this environment...
With this config...
Run '...'
See error...
Environment
npm:
Node:
OS:
platform:
Reacted by Deimantas Jakovlevas, Matt Travi and Daichi KUDO
This is trying to integrate the includePrerelease option into the range definition. This makes it very confusing.
This package already has the corresponding option available in the satisfies function. Letting users specify includePrerelease in package.json would be a much cleaner solution (see my comment).
Activity
mbtools commentedon Aug 21, 2024
This is trying to integrate the
includePrereleaseoption into the range definition. This makes it very confusing.This package already has the corresponding option available in the
satisfiesfunction. Letting users specifyincludePrereleaseinpackage.jsonwould be a much cleaner solution (see my comment).fix: include prereleases in tilde range lower bound with includePrere…