[QUESTION] Very confusing behavior for pre-release range matching

Open
#721 6 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Documentation
Clarity
Needs clarification
Activity status
Stale
Tech stack
javascript
Domain
cli, tooling

Research direction

Start by reproducing the listed npx semver --range and --include-prerelease commands, then read the README's “Prerelease Tags” section. Compare the documented behavior with the examples and related issues mentioned in the report. Done means the expected matching rules are resolved and clearly documented, or the discrepancy is narrowed to a specific implementation change.

Written by the indexing model from the issue text.

Description

When checking pre-release ranges, the results are very confusing. I have read the documentation many times, run a bunch of tests and reviewed all bug tickets. There are several open and closed issues that seem related to this, but I still can't figure out how this is expected to work. For example:

npx semver --range ">=1.0.2-0" "1.0.3-6"

Results in a non-match. Why if the range is ">=" and the range explicitly includes prereleases via "-0"? This seems to be incorrect.

npx semver --range "^1.0.2-0" "1.0.3-6"

Also results in a non-match. This seems to also be incorrect.

npx semver --range "^1.0.2-0" "1.0.3"

Results in a match. This is correct, but doesn't make sense that this would match when "1.0.3-6" does not.

 npx semver --range ">=1.0.2-0" "1.0.2-6"

Results in a match. This is correct.

So then I looked at using --include-prerelease. This seemed like the right approach based on the "Prerelease Tags" section in the README. However, this causes behavior to seem incorrect in the other extreme:

npx semver --include-prerelease --range "^1.0.2" "1.0.3-6"

Results in a match. Wait, what? This seems to completely contradict motivation expressed in the "Prerelease Tags" section.

So how can this be used effectively in automation to match versions in situations where we do want to include pre-releases from those where we do not if we cannot express that purely from the range expression itself? It seems to me that, the way this is designed, the range expression is barely (if at all) being used to decide if pre-releases are included.

Dominant language
JavaScript
Stars
5.5k
Forks
598
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from npm/node-semver

All issues in npm/node-semver

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.