Versions-LE

Versions-LE: Two Pins, One Dependency

Find where one dependency is constrained differently across a repository's manifests — and where no version can satisfy both

package.json · Cargo.toml · pyproject.toml · go.mod · GitHub workflows

---

Useful? A star or rating is how other developers find it —

★ GitHub ·

★ Open VSX ·

★ Marketplace

What it does

The build broke because api asks for regex = "1" and web asks for regex = "2", and no one version satisfies both. Or it did not break, and will: CI has built on Rust 1.80 since March while rust-version says 1.88.

Run Versions-LE: Compare Versions and every manifest in the workspace is compared as one set — or every manifest under a folder, from the Explorer. The report opens beside the editor: each problem by severity with every file, key and constraint that produced it, then what was deliberately not compared and why. Works in VS Code and in VS Code–based editors like Cursor and VSCodium (installable from Open VSX).

• In a monorepo — the crate pinned to serde 0.9 while the rest moved to 1.0
• Before a release — CI testing on a toolchain older than the minimum you publish
• Reviewing a dependency bump — the one package that did not move with the others

It never edits a manifest, and never guesses: a constraint it does not model is named and left out of every comparison.

Install

The six checks

Different and unsatisfiable are two findings. constraint-conflict is a smell; disjoint-constraint is a build that cannot resolve. They are never conflated.

Disjointness is decided by interval arithmetic over the modelled ranges, not by string comparison — which is also why >=20 and >=20.0.0 are not reported as a conflict. They are one requirement typed twice.

One finding per drifted dependency, carrying every site. A dependency constrained four ways is one problem with four sites, and four findings would read as four problems.

The four refusals

It never guesses. A constraint in a grammar this tool does not model is named in the report's refusals and takes part in no comparison — never approximated into a range.

malformed-constraint is a finding, not a refusal, and the difference is deliberate: it is the narrower verdict that the value is shaped like a constraint of its own ecosystem and is broken. The tool blames the manifest only when it is sure; everything else it blames on itself. ^^1.0.0 is malformed. latest is not — it is a syntax with a meaning this tool chose not to model.

Comparison never crosses an ecosystem. An npm semver and a Cargo semver are unrelated packages that share a word — and a bare "1.0.200" means *exactly 1.0.200* in npm and *anything below 2.0.0* in Cargo. One bridge exists, msrv-mismatch, and it is built by naming both keys rather than by matching a name.

What it reads

That last row is why this exists as much as the first: a CI toolchain drifting away from the floor a manifest declares is exactly the failure nobody notices until a release.

node_modules, vendor and .git are never read. `.github` always is — a workflow lives in a hidden directory by definition.

What it will not do

• It never edits a manifest. No --fix, no --pin, no --update. The right version for a drifted dependency is a decision, not a derivation.
• It never resolves a dependency graph. It reads what the manifests *say*, not what a resolver would pick — no lockfiles, no transitive analysis.
• It never hits the network. It does not know which versions exist, which are yanked, or which are newest; only whether two stated requirements can be met at once.
• It does not lint style. Ordering, quoting and formatting of a manifest are somebody else's job.

Use it from an AI agent

The same engine runs as an MCP server, so an agent can call it directly instead of diffing manifests by eye.

compare_versions(files: [{ path, content }], maxResults?)

It returns the report the editor renders, as data — findings capped at 500 by default with meta.truncated. It reads no files and makes no network requests. Published as versions-le-mcp on npm and as io.github.nolindnaidoo/versions-le in the MCP registry. It answers exactly as the Rust CLI's server does: one corpus runs against both, and a differential test feeds both thousands of generated manifest sets — broken JSON and TOML included — and compares every answer.

Configuring it by hand — any host with an MCP config file

{

"mcpServers": { "versions-le": { "command": "npx", "args": ["-y", "versions-le-mcp"] } } }

Or install it once with npm install -g versions-le-mcp and point at versions-le-mcp. It needs no environment variables, no API key and no configuration of its own. To check it:

echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | npx -y versions-le-mcp

The CLI

The same comparison runs over a tree from a terminal or a CI step: a Rust CLI in crate/, sharing one corpus with the extension — crate/fixtures/ — so the two can never read a constraint differently. The same command line also ships on npm as versions-le, for a machine with Node and no Rust, and CI holds it to the crate byte for byte on three operating systems.

Install it from npm (versions-le) or from crates.io (versions-le). Both install the same versions-le command.

npm install -g versions-le   # or run it once: npx versions-le

cargo install versions-le

versions-le .                          # every manifest in the tree; one JSON report on stdout when piped

versions-le --ecosystem cargo . # one ecosystem versions-le --fail-on any . # floating pins fail the build too versions-le --strict . # an unanalysed corner exits 2