Optional prerelease version lock

[protyposis]

Prerelease versions are currently only satisfied by ranges containing a prerelease tag with the same [major, minor, patch] tuple as documented, which makes sense for the default use-cases of this library.

I currently have a use-case where I want to to specify version ranges of test cases to be run for certain versions of a tested software component. E.g. to run a test on all versions that ever exist, including prerelease versions (e.g. release candidates), I want to specify the range '*'. To run a test on all versions starting with prereleases of '2.0.0', I specify the range '>=2.0.0-0'. '>=2.0.0-0' should thus match '2.0.0-rc1', '2.0.0', '2.1.0-rc1', '2.2.0', etc., which is currently prevented by the [major, minor, patch] prerelease version lock.

To be able to use this library in such cases, I added an additional parameter prereleaseLock to the satisfies method (satisfies(version, range, loose, prereleaseLock)), which is true by default to get the default version locking behavior, and disables the version lock behavior when set to false. This is basically what has been described by @isaacs in #130 (here.

[coveralls]

Coverage increased (+0.02%) to 94.659% when pulling 72fad73 on protyposis:optional-prerelease-version-lock into 8fff305 on npm:master.

[protyposis]

Package is available from the NPM repo as semver-upr.

[climblinne]

Is there any chance to get this into master?
It would be nice to get it also e.g. into max_satisfying function.

[isaacs]

This is a good idea, and addresses a real need, but I definitely feel like the maximum number of boolean options is 1 (or maybe zero), so we need to switch to an options object. Also, the default behavior should be used when the option is falsey, for consistency.

In order to prevent a backwards compatibility breakage and major version bump, we can add if (options === true) options = { loose: true } in the functions currently taking a loose param. Then add includePrerelease as a flag, and when that's truthy, all prerelease versions are included in any range based strictly on precedence ordering.

[isaacs]

(Don't feel pressure to do extra work. If you don't get to it, I will relatively soon. Just documenting the decisions here so it's not left hanging, if anyone else wants to pick it up.)

[isaacs]

Actually I lied, I had a meeting get canceled so I did it.

The question now is whether this is semver major or minor. It does change the case when you might've used a truthy non-boolean as the loose param.

[climblinne]

Thanks a lot. I think, I would go for a major change.

[protyposis]

The docs said

All methods and classes take a final loose boolean argument

so if someone provided a truthy value instead of true, he'd have used the API wrongly and just gotten lucky that it worked. Viewed like this, it would be a minor change. Since this library is used by quite a lot of people, it might make sense to take the safe route though and make it major.

Anyway, thanks for integrating this 👍

[isaacs]

The only truthy value that would cause an issue (in the current code on master) would be an object without a loose field. If you pass in any non-object truthy value, it'll explicitly coerce to { loose: true }.