semver 2.0.0 · npm ranges

Semantic version comparator

Compare two versions, test a range against npm’s rules, and sort a list — with the unintuitive cases explained rather than hidden.

Examples: ^1.2.3, ~1.2, >=2.0.0 <3.0.0, 1.x || 2.x.

Everything is parsed in this tab. Nothing is uploaded.

Short answer: fill A and B to compare, type a range to test A, and put one version per line to sort. The notes explain the edge that applies — a caret on a 0.x version, a prerelease, or build metadata.

Precedence, in one paragraph

Compare major, then minor, then patch as integers. A prerelease version is lower than its release, and prereleases compare identifier by identifier with numeric identifiers ordered numerically. Build metadata after + never affects ordering.

The two ranges people misread

Auditing what a range actually resolves to? Read the lockfile with theJSON formatter, and compare two resolved versions side by side in the text diff.

Semver questions

Why is 1.10.0 newer than 1.9.0 when it sorts first as a string?

Because semver compares numbers, not text. Sorted as strings, "1.10.0" comes before "1.9.0" — the classic bug this tool exists to avoid. The comparison here parses each component as an integer.

What does ^0.2.3 allow?

Anything from 0.2.3 up to but not including 0.3.0. A caret allows changes that do not alter the left-most non-zero digit, so for a 0.x version it is effectively a patch range — 0.2.x and 0.3.x are different, and npm treats them as incompatible.

Why does 1.0.0-rc.1 not satisfy >=0.0.0?

Because prereleases are excluded from every range unless the range itself names a prerelease on the same version tuple. It is a deliberate rule: a range like >=1.0.0 should not suddenly install 2.0.0-beta.1.

Does build metadata affect comparison?

No. 1.0.0+build.5 and 1.0.0+build.6 have equal precedence — the “+” part is ignored when ordering, though the strings differ. The page says so when it sees build metadata, instead of leaving you wondering why they compare equal.

Related tools