Version Checker

Check only the runtimes or packages the caller asks about. Do not scan all dependencies unprompted.

Detecting Local Versions

Inspect only the files relevant to the requested check:

Node.js runtime

• .node-version / .nvmrc — plain text, single version string
• package.json — engines.node field (semver range)
• package.json — volta.node field (exact version, set by Volta)
• .tool-versions — line starting with nodejs

Python runtime

• .python-version — plain text, single version string
• pyproject.toml — project.requires-python field (PEP 440 specifier)
• .tool-versions — line starting with python

npm packages

• package.json — dependencies and devDependencies version ranges

PyPI packages

• pyproject.toml — project.dependencies and project.optional-dependencies
• requirements.txt / requirements-*.txt — pinned or ranged versions

VS Code extension engine

• package.json — engines.vscode field (semver range, e.g., ^1.96.0)

If multiple sources conflict, report the discrepancy.

The patterns above cover JavaScript/TypeScript (Node.js, npm), Python, and VS Code extension ecosystems. For other runtimes or package registries, apply the same approach: check local version files and query the ecosystem's machine-readable registry endpoint following the same patterns shown here.

Looking Up Latest Versions

Run scripts/fetch-version.sh (located in this skill's directory) via Bash. It fetches registry APIs using curl and jq, returning only the needed fields as key=value lines.

The nodejs-eol and python-eol subcommands default to supported versions only. Use this default — it keeps output concise. Pass --all only when historical or already-EOL'd version data is explicitly needed.

Node.js runtime

1. Run scripts/fetch-version.sh nodejs-releases — returns latest_current, latest_current_date, latest_lts, latest_lts_codename, latest_lts_date.
2. Run scripts/fetch-version.sh nodejs-eol — returns ----separated records with cycle, eol, lts, latest for currently-supported versions only. Add --all for the full historical list.

Python runtime

1. Run scripts/fetch-version.sh python-releases — returns latest_current (newest bugfix-active version, e.g. 3.14.x) and latest_lts (second-newest bugfix-active version, e.g. 3.13.x).
2. Run scripts/fetch-version.sh python-eol — returns ----separated records with cycle, eol, latest for currently-supported versions only. Add --all for the full historical list.

npm packages

1. Run scripts/fetch-version.sh npm <package> — returns latest.

PyPI packages

1. Run scripts/fetch-version.sh pypi <package> — returns latest, requires_python.

VS Code compatibility matrix

1. Run scripts/fetch-version.sh vscode-compat <component> <version> — where <component> is node, electron, or chromium and <version> is a major (22) or major.minor (22.16), optionally v-prefixed. Returns oldest_vscode (the first VS Code release bundling that version), oldest_vscode_<component> (the exact component version in that release), oldest_vscode_created_at, and newest_vscode (the latest VS Code release still on that version).

Use this when modernizing VS Code extensions to determine the minimum engines.vscode value required after upgrading a bundled runtime. For example, after upgrading from Node 20 to Node 22, run vscode-compat node 22 to find the oldest VS Code version that ships Node 22.x.

Fallback

If any script invocation outputs a line starting with error:, fall back to direct fetching:

1. Call ToolSearch with query select:WebFetch to load the tool schema.
2. Read references/known-endpoints.md for the endpoint URL and response schema.
3. Use WebFetch to fetch the endpoint and extract the needed fields from the JSON response.

Assessing EOL Status

• For runtimes: cross-reference with endoflife.date API (https://endoflife.date/api/{product}.json).
• A version is EOL if its eol date is in the past relative to today.
• Flag versions entering EOL within the next 6 months as "approaching EOL."

Output Format

Present results using this structure:

## Summary
1-2 sentence overview of findings.

## Findings
For each checked item:
- **Item name** (e.g., Node.js, react, Flask)
  - Current: <local version or range>
  - Latest LTS: <version> (if applicable)
  - Latest stable: <version>
  - EOL status: <active | approaching EOL (date) | EOL since (date)>
  - Recommended target: <version>

## Recommendations
Actionable next steps, ordered by priority (EOL items first, then outdated items).

Rules

• Fetch live data for every check. Do not rely on training data for version numbers.
• If a fetch fails, report the failure and the URL attempted. Do not guess.
• Distinguish between LTS and Current/stable where the ecosystem makes that distinction (Node.js). For ecosystems without an LTS concept (PyPI packages), report only latest stable.
• When the local version satisfies the latest LTS or stable, say so explicitly — do not suggest unnecessary upgrades.