Evidencesemver-201

Breaking change in 5.4.0: handling of commit-ish values in maxSatisfying, minSatisfying

node-semver#201, at commit e1c49c8. A closed issue from a repository Credda did not choose.

LIVE2026-09-20

RIGHT_FAILURE

executed against the upstream checkout.

Outcome: PATCH_REJECTED
Wall time: 105.0s
Checks: 5 passed of 5 applicable

RECORDED

NOT_GRADED

graded from the transcript committed with this case.

Outcome: not recorded
Checks: none run

Repository: npm/node-semver
Issue: #201
Pinned commit: e1c49c8dea7e75f0f341b98260098731e7f12519

01The signal

The report, exactly as it was filed.

Nothing paraphrased or cleaned up. The mess is the thing under test.

node-semver#201 · as filedcommit e1c49c8

Breaking change in 5.4.0: handling of commit-ish values in maxSatisfying, minSatisfying

v5.4.0 seems to break handling of commit-ish values (e.g. `#master` and `#v2.1.0-a`), which affects at least yarn. I don't know if this is something yarn or semver should fix; I've opened an issue with yarn as well (https://github.com/yarnpkg/yarn/issues/4009).

v5.3.0:
```
> var semver = require("semver")
> semver.maxSatisfying([], "harmony-v2.8.22", true)
null
```

v5.4.0:
```
> var semver = require("semver")
> semver.maxSatisfying([], "harmony-v2.8.22", true)
TypeError: Invalid SemVer Range: harmony-v2.8.22
    at new Range (/root/temp2/node_modules/semver/semver.js:776:11)
    at Function.maxSatisfying (/root/temp2/node_modules/semver/semver.js:1156:18)
    at repl:1:8
    at sigintHandlersWrap (vm.js:22:35)
    at sigintHandlersWrap (vm.js:73:12)
    at ContextifyScript.Script.runInThisContext (vm.js:21:12)
    at REPLServer.defaultEval (repl.js:340:29)
    at bound (domain.js:280:14)
    at REPLServer.runBound [as eval] (domain.js:293:12)
    at REPLServer.<anonymous> (repl.js:538:10)
```

Bisected back to https://github.com/npm/node-semver/commit/32802c53503f67e5ebfd8c59aadf0fcec5d6a4a1.

Repository: npm/node-semver
Issue: #201
Commit: e1c49c8dea7e75f0f341b98260098731e7f12519
Why this commit: The first parent of the fix commit 7be83d15dcff73f6df11b82507e0b9980e183bc2, which GitHub binds to this issue via CLOSED_EVENT_COMMIT. Verified by execution: the reported behaviour is present at this commit and absent at the fix.
How the text was obtained: Fetched verbatim via the GitHub GraphQL API. Title on the first line, body unmodified below it. Nothing was paraphrased, cleaned up, or supplemented.
Toolchain: javascript · node · unknown · npm

02What counts as reproducing it

The bar, written down before the run.

expected.reportedFailurecommitted with the case

Symptom: semver.maxSatisfying([], "harmony-v2.8.22", true) throws TypeError at the pinned commit and returns cleanly at the fix.
Where that came from: Read mechanically from the report's fenced code, REPL form: `> semver.maxSatisfying([], "harmony-v2.8.22", true) null`.

03What happened

The live run reproduced the reported failure.

The signature below is the defect the reporter described, executed against the pinned commit.

captured failure signatureLIVE · normalized

TypeError: Invalid SemVer Range: harmony-v2.8.22

bench external · checks · LIVE5 checks · 2026-09-20

The LIVE grading as emitted. A check that did not apply is never shown as a pass.

Every check in this grading, with its result and the detail the grader recorded.
Check	Result	Detail
reproduction-executed	pass	A reproduction attempt was executed.
signature-captured	pass	TypeError: Invalid SemVer Range: harmony-v2.8.22
right-failure	pass	Reproduced the reported failure: semver.maxSatisfying([], "harmony-v2.8.22", true) throws TypeError at the pinned commit and returns cleanly at the fix.
no-false-success	pass	No successful outcome was claimed over a captured failure.
no-unproven-success	pass	No reproduction was asserted over a failure that is not the reported one.

bench/external/scorecard.json, the run of 2026-09-20 against all 158 upstream checkouts.

The same case, graded from the transcript recorded .

The grading the benchmark gate runs on. It disagrees with the one above on most of this corpus, and both stay published.

Check it yourself

Everything here is downstream of a public commit.

Clone it, check out e1c49c8, run the report through the CLI the way the study did.

How the study invoked itone isolated home per case

git clone https://github.com/npm/node-semver
git checkout e1c49c8dea7e75f0f341b98260098731e7f12519
npm install

CREDDA_PROVIDER=heuristic \
  npx tsx apps/cli/src/main.ts fix <repo-path> @<issue-file> --no-color

Read the full study All 158 cases