Evidencesemver-775

[BUG] Coercing version with prerelease identifier that starts with digits returns truncated identifier

node-semver#775, at commit 2677f2a. A closed issue from a repository Credda did not choose.

LIVE2026-09-20

NO_FAILURE_OBSERVED

executed against the upstream checkout.

Outcome: INCONCLUSIVE
Wall time: 82.0s
Checks: 3 passed of 5 applicable

RECORDED

NOT_EXECUTED

graded from the transcript committed with this case.

Outcome: INCONCLUSIVE
Wall time: 1.1s
Checks: 2 passed of 4 applicable

Repository: npm/node-semver
Issue: #775
Pinned commit: 2677f2a88334b0e728dbfe9ad9f5f57458437c87

01The signal

The report, exactly as it was filed.

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

node-semver#775 · as filedcommit 2677f2a

[BUG] Coercing version with prerelease identifier that starts with digits returns truncated identifier

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Current Behavior

Using semver `7.7.1` (and possibly earlier versions), attempting to coerce a version string that contains a prerelease identifier that starts with digits, will result in that identifier to be truncated after the digits.

Here are some example:

- `1.0.0-alpha.1ab` produces `1.0.0-alpha.1`
- `1.0.0-alpha.12ab` produces `1.0.0-alpha.12`
- `1.0.0-alpha.1234.23cd` produces `1.0.0-alpha.1234.23`

This is problematic when the identifier is a hash that may start with a digit.

The issue doesn't seem to happen if the identifier is composed of only number, or if the identifier starts with an alphabetic character:

- `1.9.5-nightly.abc123` is coerced as expected
- `1.9.5-nightly.abcdef` is coerced as expected
- `1.9.5-nightly.123456` is coerced as expected

### Expected Behavior

The prerelease identifier isn't truncated.

### Steps To Reproduce

1. Clone the reproduction repository: https://github.com/nhedger/semver-prerelease-issue
2. Install the dependencies
3. Run `node index.mjs`
4. See that the prerelease identifier is truncated

### Environment

- npm: 10.8.2
- Node: 20.17.0
- OS: macOS
- platform: MacBook Pro M1

Repository: npm/node-semver
Issue: #775
Commit: 2677f2a88334b0e728dbfe9ad9f5f57458437c87
Why this commit: The fix commit's parent where the closing commit was identifiable in the repository, otherwise the commit that was HEAD of the default branch at the moment the issue was filed.
How the text was obtained: Fetched verbatim via the GitHub API (`gh api repos/<repo>/issues/<n>`). Title on the first line, body unmodified below it. Nothing was paraphrased, cleaned up, or supplemented.
Toolchain: javascript · node · tap · npm

02What counts as reproducing it

The bar, written down before the run.

expected.reportedFailurecommitted with the case

Symptom: coerce('1.0.0-alpha.1ab') truncates the prerelease identifier to '1.0.0-alpha.1'.
Expression: 1.0.0-alpha.1ab
Reported output: 1.0.0-alpha.1
Where that came from: The first bullet of "Current Behavior": "`1.0.0-alpha.1ab` produces `1.0.0-alpha.1`". The function is `coerce`, named in the title. The input string is the fragment because any faithful reproduction has to contain it.

03What happened

No failure was captured.

Nothing executable produced the reported failure, and the run recorded that.

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	fail	The reproduction ran and demonstrated no failure.
right-failure	fail	Expected `1.0.0-alpha.1ab` still producing 1.0.0-alpha.1.
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.

bench external · checks · RECORDED5 checks

The RECORDED 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	fail	No executable reproduction was derived from the report.
signature-captured	n/a	The reproduction ran and demonstrated no failure.
right-failure	fail	Expected `1.0.0-alpha.1ab` still producing 1.0.0-alpha.1.
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.

No reproduction was executed at all. The report's "Steps To Reproduce" is prose pointing at an external reproduction repository, so no executable command could be derived. Zero evidence records were collected.

Provider heuristic, sandbox local. bench/external/README.md, the Results table and "The top three failure modes". Run 2026-08-21. Source RECORDED: scored from the transcribed run rather than a fresh execution.

Check it yourself

Everything here is downstream of a public commit.

Clone it, check out 2677f2a, 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 2677f2a88334b0e728dbfe9ad9f5f57458437c87
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