Semver Compare
Sort versions, compare two, and test npm ranges — strict SemVer 2.0.0, coercion shown separately.
Newest
2.0.0
Ascending
1.0.0+build.7 < 1.2.3-beta.11 < 1.2.3 < 1.9.3 < 1.10.0 < 2.0.0-rc.1 < 2.0.0
| Line | Strict | Read as | npm would coerce |
|---|---|---|---|
| 2.0.0 | yes | 2.0.0 | — |
| 1.9.3 | yes | 1.9.3 | — |
| 1.10.0 | yes | 1.10.0 | — |
| 2.0.0-rc.1 | yes | 2.0.0-rc.1 | — |
| 1.2.3-beta.11 | yes | 1.2.3-beta.11 | — |
| v1.2.3 | yes | 1.2.3 | — |
| 1.0.0+build.7 | yes | 1.0.0+build.7 | — |
- Strict SemVer 2.0.0 parse (the semver package, non-loose): a single leading v is accepted, = is not — measured against the installed engine and pinned in tests, disclosed here.
- Comparison is spec precedence: numeric identifiers numerically, alphanumeric lexically, a prerelease sorts before its release, and +build metadata is ignored by comparison entirely (spec §10) — reported as its own fact when it is the only difference.
- Ranges are node-semver syntax, including the tuple-scoped prerelease rule: a range with a prerelease comparator only unlocks prereleases of that same major.minor.patch — 1.1.0-beta.1 does NOT satisfy ^1.0.0.
- Coercion is a separate, lossy answer (“what npm would coerce this to”), never mixed into the strict verdict.
Done
Finished here in the tab. Nothing was uploaded.
sorting uses spec precedence — 1.10.0 > 1.9.3, not string order