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
semver.satisfies(): '*' doesn't match prerelease identifiers #130
Even after browsing that issue, it is unclear to me why a specifier that literally means "anything" should not match... well, anything. Additionally, it appears that there is no way, then, to construct such a comparison?
@myndzi The principle at work here is that 0.3.16-foo.1 is a "prerelease" version. Prereleases can include breaking changes at any time, and frequently don't even satisfy the API contracts inherent in a module, so they're excluded from any ranges that don't explicitly opt-in to a pre-release version in that chain. So, for example, it would match ~0.3.16-alpha, but that range would not be satisfied by 0.3.17-foo.1, because that is a prerelease of a different version.
I can understand this, to an extent, in the context of a partial version (say, 1.*), but * is literally "everything", so how can anything fall "outside" this range?
More importantly, I guess, it seems that the ability to opt in to or out of prerelease matches should more properly be an option passed to the semver.satisfies function, so that the user can control the behavior, rather than a forced behavior that only satisfies one of two needs...
Having an option to allow prerelease matches against non-prerelease version ranges would be fine. It'd be tricky to get the API right, though, especially since there's already one boolean and adding another one edges a bit too far down the slippery slope of long function signatures. Maybe it'd be ok to replace the loose params with an options object, or have loose matches also allow prerelease versions to match against ranges?
In my opinion new x-ranges for prerelease versions would be a good idea. For example 1.3.*-* should match to all prereleases of 1.3.*, and * || *-* to any version at all (prerelease or not).
Activity
megawac commentedon Jul 13, 2015
See #123, related npm/npm#8855
myndzi commentedon Jul 13, 2015
Even after browsing that issue, it is unclear to me why a specifier that literally means "anything" should not match... well, anything. Additionally, it appears that there is no way, then, to construct such a comparison?
isaacs commentedon Jul 13, 2015
@myndzi The principle at work here is that
0.3.16-foo.1is a "prerelease" version. Prereleases can include breaking changes at any time, and frequently don't even satisfy the API contracts inherent in a module, so they're excluded from any ranges that don't explicitly opt-in to a pre-release version in that chain. So, for example, it would match~0.3.16-alpha, but that range would not be satisfied by0.3.17-foo.1, because that is a prerelease of a different version.myndzi commentedon Jul 13, 2015
I can understand this, to an extent, in the context of a partial version (say,
1.*), but*is literally "everything", so how can anything fall "outside" this range?myndzi commentedon Jul 13, 2015
More importantly, I guess, it seems that the ability to opt in to or out of prerelease matches should more properly be an option passed to the
semver.satisfiesfunction, so that the user can control the behavior, rather than a forced behavior that only satisfies one of two needs...isaacs commentedon Jul 14, 2015
Having an option to allow prerelease matches against non-prerelease version ranges would be fine. It'd be tricky to get the API right, though, especially since there's already one boolean and adding another one edges a bit too far down the slippery slope of long function signatures. Maybe it'd be ok to replace the
looseparams with an options object, or haveloosematches also allow prerelease versions to match against ranges?qzb commentedon Jul 14, 2015
In my opinion new x-ranges for prerelease versions would be a good idea. For example
1.3.*-*should match to all prereleases of1.3.*, and* || *-*to any version at all (prerelease or not).