Versions-LE

io.github.nolindnaidoov1.0.0更新于 Oct 4, 2026

Find where one dependency is constrained differently across a repository's manifests.

已验证STDIO仅桌面Developer Tools

概览

AI 生成的概览

让助手比较仓库各清单文件中的依赖约束,并报告版本冲突或无法同时满足的情况。

功能
提供 compare_versions 工具,接收清单文件的路径与内容参数并返回结构化报告。它检查 package.json、Cargo.toml、pyproject.toml、go.mod 和 GitHub 工作流文件,找出互斥约束、需求冲突、MSRV 不匹配、预发布版本固定和浮动固定。它从不修改清单、不解析依赖图、不发起网络请求;未建模的约束会作为拒绝项列出并排除在比较之外。
适用场景
适用于 monorepo 或多清单项目:排查构建无法解析的原因、审查依赖升级,或核对 CI 工具链固定版本是否与声明的最低版本一致。适合需要机器可读漂移报告、而非人工比对清单的助手。
运行要求
通过 npx versions-le-mcp 以 stdio 在本地运行(需要 Node.js),也可用 npm 全局安装。无需环境变量、API 密钥或额外配置。该工具自身不读取文件,清单内容由参数传入。
安装前请注意
只读:从不修改清单,也不发起网络请求,因此不涉及凭据或密钥。结果默认上限为 500 条,meta.truncated 表示被截断。它不知道哪些版本存在、被撤回或最新,结论仅针对所声明需求能否同时满足。

安装

在 SourceWeft 中

  1. 打开 控制台中的 Versions-LE,将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。

其他 MCP 客户端

参照 仓库 中的启动说明。

README

[Versions-LE Logo]

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

[Install from VS Code Marketplace] [Open VSX downloads] [versions-le-mcp on npm] [versions-le on crates.io] [LE Tools]


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.

Press Ctrl+Alt+V (Cmd+Alt+V on Mac) 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

WhereWhat you getInstall
VS CodeThe comparison, in your editor, on a keystrokeMarketplace
Cursor, VSCodium, WindsurfThe same extensionOpen VSX
A terminal or a CI stepA whole tree, with an exit codecargo install versions-le · crates.io
Any MCP agent, via Nodecompare_versions over stdionpx versions-le-mcp · npm
ZedThe MCP server as a context serveradd it by hand (no listing yet)

The six checks

CodeSeverityWhat it means
disjoint-constrainterrorTwo constraints for one dependency that no single version satisfies. The strongest claim this tool makes.
malformed-constrainterrorShaped like a constraint of its own ecosystem, and broken.
constraint-conflictwarningOne dependency, two or more different requirements across sites.
msrv-mismatchwarningrust-version differs across manifests, or a CI toolchain pin is below the declared minimum.
prerelease-in-productionwarningAn -rc or -alpha constraint outside dev or build dependencies.
floating-pininfolatest, *, a caret on a 0.x version, or an unpinned CI tool version.

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.

ReasonWhen
unknown_grammarThe value is a constraint in a syntax this tool does not model: PEP 440 ~=, !=, ===, ==1.2.*; npm workspace:, npm:, file:, link:, a git or https URL, an owner/repo shorthand, a dist tag; a Cargo dependency table with no version; a commit-SHA or branch action ref; a CI channel name (stable, latest, lts/*).
cross_ecosystemThe same name appears under two ecosystems. Named once, with a site in each, and the two are never compared.
ambiguous_version_stringA <tool>-version: value in a workflow that is not evidently a version — ${{ matrix.node }}, a list, a filename. No entry is created at all: there is nothing to compare and nothing was invented.
per_job_tool_versionOne CI tool installed at two versions — python-version: 3.9 in the test job, 3.12 in the publish job. A tool version belongs to the job that installs it, so the two are never compared.

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

ManifestKeys
package.jsonthe four dependency sections, engines.*, packageManager
Cargo.tomldependencies, dev, build, the workspace and target variants, rust-version
pyproject.tomlPEP 621 dependencies, optional-dependencies, requires-python
go.modrequire (single and block form), the go directive
.github/workflows/*.ymluses: action refs, <tool>-version: inputs, toolchain:

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.

EditorHow
VS Code 1.101+Nothing to install — the extension registers compare_versions with agent mode
ZedNo listing yet — add the MCP server by hand
Claude Codeclaude mcp add versions-le -- npx -y versions-le-mcp
Cursor, Windsurf, anything elsepoint it at npx versions-le-mcp
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
json
{  "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:

bash
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.

[versions-le in a terminal]

bash
versions-le .                          # every manifest in the tree, as one JSON reportversions-le --ecosystem cargo .        # one ecosystemversions-le --fail-on any .            # floating pins fail the build tooversions-le --strict .                 # an unanalysed corner exits 2versions-le mcp                        # compare_versions and versions_le_check over MCP on stdio

The exit code is the product — 0 nothing above info, 1 findings, 2 the question was malformed. No manifests at all is 0: nothing can conflict with nothing.

Commands

CommandDescription
Versions-LE: Compare Versions (Ctrl+Alt+V / Cmd+Alt+V)Compare every manifest in the workspace, or under the folder picked in the Explorer
Versions-LE: Open SettingsOpen Versions-LE settings
Versions-LE: Help & TroubleshootingBuilt-in documentation

Settings

SettingDefaultDescription
versions-le.exclude[]Glob patterns for manifests to leave out; node_modules, .git and vendor are always left out
versions-le.openResultsSideBySidetrueOpen the report beside the current editor
versions-le.copyToClipboardEnabledfalseAlso copy the report to the clipboard
versions-le.notificationsLevelsilentall = every notification, important = warnings + errors, silent = errors only
versions-le.statusBar.enabledtrueShow the status bar item
versions-le.telemetryEnabledfalseLocal-only event log (see Privacy)

Languages

Twelve languages besides English:

German · Spanish · French · Indonesian · Italian · Japanese · Korean · Portuguese (Brazil) · Russian · Ukrainian · Vietnamese · Chinese (Simplified)

Both halves are covered — the manifest (command titles, setting names and descriptions) and everything shown while the extension runs (notifications, the status bar and the report's headings). A finding's message is the engine's English, identical to the CLI's.

Privacy & security

  • No network access. The extension never sends data anywhere; it does not know which versions exist, only whether two stated requirements can be met at once. The telemetryEnabled setting only writes events to a local Output Channel you can inspect (Versions-LE).
  • It reads manifests and nothing else, and never writes to one.
  • The MCP server holds the same line. It takes content as an argument and returns data: no filesystem access, no network calls, no telemetry.
  • Error notifications redact home directories and credential-shaped fragments.

Documentation

WhatWhere
What the tool is allowed to say — checks, refusals, the output contract, non-goalscrate/SPEC.md
How the extension is built and held together — architecture, invariants, toolchain, releaseAGENTS.md
How the CLI is built and held togethercrate/AGENTS.md
What changedCHANGELOG.md · crate/CHANGELOG.md
The tool's page, and the other fifteenletools.dev/tools/versions-le

Performance

InputSizeFoundTimeRateScan speed
50 crates, 50 packages0.01 MB4502.37 ms189,660/sec6.1 MB/s
500 crates, 500 packages0.15 MB4,50019.25 ms233,818/sec7.6 MB/s
2,000 crates, 2,000 packages0.58 MB18,000197.84 ms90,983/sec3 MB/s

Median of 7 runs after warmup, on Apple M5 Pro, 24 GB RAM, Node 24.3.0. Inputs are generated by scripts/benchmark.ts rather than checked in, so the sizes above are exactly what was measured. Reproduce with bun run benchmark.

These are machine-specific and are not asserted in CI — a benchmark that gates a build only tells you how busy the runner was.

Testing

MetricCoverage
Statements86.91%
Branches79.62%
Functions94.44%
Lines90.66%

265 test cases across 13 files, plus an integration suite that runs in a real VS Code extension host and an end-to-end test that installs the built .vsix into a clean profile.

Generated from a real run — coverage/coverage-summary.json and coverage/test-results.json — by scripts/coverage-readme.js; CI fails if this section drifts. Reproduce with bun run test:coverage, and the case count is the one vitest prints.

More from the LE family

Sixteen single-purpose tools for the work in front of every model. Each ships a Rust CLI and an MCP server. One page: letools.dev

Get it out

  • String-LE — Extract every string in a codebase, with its position, so a person can read them
  • Numbers-LE — Extract every hardcoded number in a codebase, so a person can check them
  • Units-LE — Extract every quantity with its unit, normalized, and refuse the ambiguous ones by name
  • Dates-LE — Extract every date and timestamp, and the exact instant each one resolves to
  • IDs-LE — Extract every UUID, ULID, NanoID, ObjectId and Snowflake, and decode the time inside
  • IPs-LE — Extract every IP address, CIDR block and MAC, normalized and classified by scope
  • URLs-LE — Extract every URL in a codebase, with its protocol and exact position
  • Paths-LE — Extract every file path in a codebase, and say whether it still points at anything
  • Colors-LE — Extract every color in a codebase, and say which ones are not in your palette

Check it

  • Regex-LE — Find every regex in a codebase, and report which can be driven into catastrophic backtracking
  • Versions-LE — Find where one dependency is constrained differently across a repository's manifests
  • i18n-LE — Identify the i18n library a project uses, then audit its catalogs by that library's rules
  • Scrape-LE — Check whether a page is scrapeable before the scraper is written, and say when it cannot tell

Guard it

  • Secrets-LE — Find hardcoded credentials in a codebase, and never print one into the report
  • EnvSync-LE — Compare the dotenv files in a tree, and say which keys are missing from which
  • Unicode-LE — Find the Unicode that hides meaning — bidi controls, invisibles, homoglyphs, mixed scripts

Each stands on its own: no shared crate, no published core. Where two of them agree, it is because the same answer was right twice.

Contact — nolindnaidoo.com · GitHub · LinkedIn

Also by nolindnaidoo

Rust — pixelcoords and pixelactions are one loop: pixelcoords answers where, pixelactions acts there. Their own tools, their own voice — not part of the LE family.

License

MIT © nolindnaidoo

来源:README.md,提交 2e95d72

工具

0
工具元数据尚未被收录。

版本历史

1
  1. v1.0.0最新Oct 4, 2026