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
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:
The text was updated successfully, but these errors were encountered:
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).
Is there an existing issue for this?
Current Behavior
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 like1.0.*-rc
doesn't really make much sense and isn't terribly useful. Presumably the resolution to this problem is one of the following:1.x.x
OR versions with the exact prereleaseHowever 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
Environment
The text was updated successfully, but these errors were encountered: