SemVer Conflict Solver

Why a normal version checker cannot answer this

Every existing single-package semver tool takes one package name and one range. That answers "does 1.2.3 match ^1.0.0?", which is not the question you have when a build fails with ERESOLVE. The question there is whether several ranges admit a common version at all, and if not, which ones are responsible.

The difference is not cosmetic. Ranges combine as an intersection of unions: each range may list alternatives with ||, and the whole set resolves only if some choice from each range overlaps every other choice. On top of that sits the prerelease rule, which quietly excludes prerelease versions unless a comparator names the same major.minor.patch with a prerelease of its own. Working that out by hand, or asking a chatbot, produces confident wrong answers far more often than right ones. This page computes it with the same algorithm npm itself uses.

The rules this implements, and the ones people get wrong

Range	Really means	The trap
^1.2.3	>=1.2.3 <2.0.0-0	None, for a 1.x. This is the well-behaved case.
^0.2.3	>=0.2.3 <0.3.0-0	The caret stops at the next minor, not the next major, because 0.x already signals breaking changes.
^0.0.3	>=0.0.3 <0.0.4-0	It admits exactly one version. Often read as "any 0.0.x", which is wrong.
^0.0	>=0.0.0 <0.1.0-0	Adding the patch changes the meaning completely.
~1.2.3	>=1.2.3 <1.3.0-0	Tilde allows patch changes only when a minor is written out.
~1.2	>=1.2.0 <1.3.0-0	Same as 1.2.x. Tilde and caret differ only above 0.x.
>1	>=2.0.0	An operator on a partial version is absorbed by the expanded range. It does not mean "greater than 1.0.0".
1.2.3 - 2	>=1.2.3 <3.0.0-0	The open end of a hyphen range bumps to the next major, not to 2.x.
1.2.3-rc.1 vs ~1.2.0	no overlap	The prerelease rule: ~1.2.0 names no prerelease, so 1.2.3-rc.1 is excluded even though it is numerically inside.

What "smallest conflicting group" means

When a set does not resolve, the useful answer names the constraints responsible, not just the fact of failure. This page searches for the smallest subset that already fails on its own. That distinction matters because pairwise checking is not enough: three ranges can each pair cleanly with both others and still have no common version. In that case there is no conflicting pair to point at, only a conflicting combination, and the page says so instead of naming an innocent constraint.

What it will not tell you

A range that resolves still may have no published version behind it, which is why the registry lookup is offered separately and only runs when you supply a package name. This page does not read package.json, does not walk a dependency tree, and does not know about lockfiles, overrides, patch versions or --legacy-peer-deps. Different packages are versioned independently, so two lines for two different packages can never conflict; every line here is a constraint on one package. Version strings in the registry are sorted with semver precedence, not alphabetically, because the registry returns them unordered.

Frequently Asked Questions

What is an ERESOLVE error?

It is what npm prints when two packages demand incompatible versions of a shared dependency. It is tedious to diagnose by hand because the two demands usually come from different files, one of them a transitive dependency you did not write yourself.

Why does my caret range not allow the update I expected?

Most often the package is on 0.x. ^0.2.3 stops at <0.3.0-0 and ^0.0.3 allows a single version, because a 0.x major already carries breaking changes. The expansion table above shows the exact bound for each of your ranges.

Does this use the same rules as npm?

It implements node-semver's range grammar and prerelease rule, including the absorption of operators into partial versions and the rejection of operators on either side of a hyphen range. Every rule here was checked against the semver package npm itself depends on.

Does my data leave the browser?

Only if you enter a package name, in which case that one name is sent to the npm registry to list published versions. Constraint solving, expansion and version checking all run on this page.

Why does it report no conflict pair?

Because the failing set needs three or more constraints at once, or because the prerelease rule excludes a version that sits numerically inside every bound. The smallest conflicting group is the accurate answer in both cases.

Can I check a single version instead?

Yes. Put the version in the version field below the results and it is tested against every line at once, which also shows you exactly which line rejects it.