Good first issue, and a genuinely small one. This is first-timers-only, so if you have contributed here before please leave it for someone who has not.
The problem
positionAgainstRange in src/utils/version.ts classifies a version as satisfies, below, above or outside a semver range. It was recently fixed (#1240) so that it agrees with satisfiesRange on prerelease versions. The fix is correct, but nothing tests it, so a future change could silently undo it.
Specifically: the function passes the raw range to semver's satisfies/ltr/gtr, and uses validRange only as a guard. If someone "tidies" that by comparing against validRange's normalized output instead, prerelease handling breaks again and every existing test still passes.
Reproduce the gap
On main, change positionAgainstRange so the three semver calls receive semver.validRange(trimmedRange, { loose: true }) instead of trimmedRange. Then:
npm test -- tests/utils/version-extensions.test.ts
All 60 tests pass, even though the behaviour has regressed:
| input |
correct |
with the regression |
positionAgainstRange("3.0.0-rc.1", "3.x") |
"satisfies" |
"below" |
positionAgainstRange("3.0.0-rc.1", "1.x || 3.x") |
"satisfies" |
"outside" |
What to change
Add a test to tests/utils/version-extensions.test.ts asserting the correct values above. Either input works; both is better.
Please verify it actually catches the problem: make the regression above, confirm your new test fails, then revert and confirm it passes. A test that passes either way is worse than no test, because it looks like coverage.
Getting started
npm install, then npm test to confirm a clean start (currently 2127 tests)- branch as
test/issue-NNN-short-description
Closes #NNN in the PR body
Ask here if anything is unclear.
Good first issue, and a genuinely small one. This is first-timers-only, so if you have contributed here before please leave it for someone who has not.
The problem
positionAgainstRangeinsrc/utils/version.tsclassifies a version assatisfies,below,aboveoroutsidea semver range. It was recently fixed (#1240) so that it agrees withsatisfiesRangeon prerelease versions. The fix is correct, but nothing tests it, so a future change could silently undo it.Specifically: the function passes the raw range to semver's
satisfies/ltr/gtr, and usesvalidRangeonly as a guard. If someone "tidies" that by comparing againstvalidRange's normalized output instead, prerelease handling breaks again and every existing test still passes.Reproduce the gap
On
main, changepositionAgainstRangeso the three semver calls receivesemver.validRange(trimmedRange, { loose: true })instead oftrimmedRange. Then:All 60 tests pass, even though the behaviour has regressed:
positionAgainstRange("3.0.0-rc.1", "3.x")"satisfies""below"positionAgainstRange("3.0.0-rc.1", "1.x || 3.x")"satisfies""outside"What to change
Add a test to
tests/utils/version-extensions.test.tsasserting the correct values above. Either input works; both is better.Please verify it actually catches the problem: make the regression above, confirm your new test fails, then revert and confirm it passes. A test that passes either way is worse than no test, because it looks like coverage.
Getting started
npm install, thennpm testto confirm a clean start (currently 2127 tests)test/issue-NNN-short-descriptionCloses #NNNin the PR bodyAsk here if anything is unclear.