[BUG] minVersion returns 0.0.0 when a 0.0.0 prerelease is the true minimum #934

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

This is admittedly a bit pedantic, but minVersion seems to treat 0.0.0 as a special case. A prerelease lower bound is respected on every tuple except 0.0.0:

semver.minVersion('>=1.0.0-alpha <2.0.0').version // '1.0.0-alpha'
semver.minVersion('>=0.0.1-alpha <1.0.0').version // '0.0.1-alpha'
semver.minVersion('>=0.0.0-alpha <1.0.0').version // '0.0.0'

The same thing happens with includePrerelease, where 0.0.0-0 satisfies * but 0.0.0 is returned:

semver.minVersion('*', { includePrerelease: true }).version // '0.0.0'

This comes from the shortcut at the top of ranges/min-version.js, which tries 0.0.0 before 0.0.0-0 and returns the first one that matches.

Expected Behavior

I'd expect '0.0.0-alpha' and '0.0.0-0' respectively, since the README describes minVersion as returning "the lowest version that can match the given range", and the rest of the library agrees that these sort below 0.0.0 (lt, sort, minSatisfying).

I couldn't find anything (docs, tests, or the original PR #241) suggesting 0.0.0 is meant to be special here, so I suspect the shortcut just wasn't written with prerelease lower bounds in mind. But if this is intentional it might be worth documenting.

Steps To Reproduce

1. npm install semver@7.8.5
2. Run node -e "console.log(require('semver').minVersion('>=0.0.0-alpha <1.0.0').version)"
3. See 0.0.0

Environment

• npm: 11.20.0
• Node: 26.12.1
• OS: macOS 26.6.1
• platform: Apple Silicon (arm64)
• semver: 7.8.5 (same code on main)

AI disclosure: this issue was discovered with AI assistance