feat(cli): resolve partial versions from the tool-versions data

[viceice]

Changes

• install-tool <tool> <prefix> (e.g. 20, 3.12) resolves to the newest release of that line, for tools without their own version resolver.
• The versions come from the online tool-versions data (containerbase.github.io/tool-versions/v1/<tool>.json, via the http service, so proxies and URL replacements apply); the embedded data is only used, with a warning, when the online data can't be read. The online lookup has a 30 s timeout and no retries.
• A version that is itself a release stays as it is; tools with a specific resolver are unchanged.
• Docs: partial versions.

Layer 4 of #7768.

Context

Please select one of the following:

• This closes an existing Issue, Closes: #
• This doesn't close an Issue, but I accept the risk that this PR may be closed if maintainers disagree with its opening or implementation

AI assistance disclosure

Did you use AI tools to create any part of this pull request?

Please select one option and, if yes, briefly describe how AI was used (e.g., code, tests, docs) and which tool(s) you used.

• No — I did not use AI for this contribution.
• Yes — minimal assistance (e.g., IDE autocomplete, small code completions, grammar fixes).
• Yes — substantive assistance (AI-generated non‑trivial portions of code, tests, or documentation).
• Yes — other (please describe):

Claude Sonnet 5.5 and Claude Opus 5.5 (Claude Code) wrote the changes, tests and docs, reviewed by @viceice.

Use of AI in replying to PR comments

Who answers review comments:

• @viceice will read and reply directly. Name the account.
• An agent will draft replies and @username will read them before they are posted. Name the account.
• An agent will draft replies and reply autonomously. This is heavily discouraged, and we prefer that there are humans in the loop
• Nobody has explicitly committed to replying.

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified tests

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[viceice]

/review

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📎 Requirement gaps (1)

1. CLI runtime still validates version files 📎 Requirement gap

Description

ToolVersionsService.validate() calls ToolVersions.safeParse() after both embedded JSON.parse()
reads and online HTTP responses. Every tool-version file therefore remains subject to runtime schema
validation instead of treating parsed data as unvalidated input, including the new online lookup
path.

Code

src/cli/services/tool-versions.service.ts[R99-105]

+  private validate(
+    tool: string,
+    data: unknown,
+    source: string,
+  ): ToolVersionsData | undefined {
+    const result = ToolVersions.safeParse(data);
+    if (!result.success) {

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Tool-version data is still validated at CLI runtime with `ToolVersions.safeParse()`, contrary to the lazy embedded-data contract.

## Fix Focus Areas
- src/cli/services/tool-versions.service.ts[99-113]

## Recommended Fix
Remove the runtime schema validation from the embedded and online loading paths. Parse the requested JSON file with `JSON.parse`, return the parsed data when readable, and continue treating missing or unreadable files as unavailable data without performing schema validation in the CLI.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Dismiss ↗ | View ↗

---

2. A misrouted file picks another tool's version 🐞 Bug

Description

ToolVersionsService.validate() accepts a schema-valid online response without checking that its
tool field matches the requested tool. If an online response or URL replacement serves a different
tool's file, resolvePartial() uses its versions instead of rejecting the file and trying embedded
data.

Code

src/cli/services/tool-versions.service.ts[R104-113]

+    const result = ToolVersions.safeParse(data);
+    if (!result.success) {
+      logger.debug(
+        // the first issue is enough to find the problem
+        { tool, issue: result.error.issues.slice(0, 1) },
+        `invalid ${source} tool-versions data`,
+      );
+      return undefined;
+    }
+    return result.data;

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Schema-valid online data for a different tool can determine the installed version.
## Fix Focus Areas
- src/cli/services/tool-versions.service.ts[99-113]
- src/cli/install-tool/tool-version-resolver.service.ts[98-104]
## Recommended Fix
Reject parsed data when its `tool` field differs from the requested tool, so the existing unavailable-data path can use embedded versions.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Dismiss ↗ | View ↗

---

View medium (1)

3. Missing version data logs a false error 🐞 Bug

Description

ToolVersionsService.fetch() calls getJson() for an optional file, but the HTTP service logs a
404 as download failed at error level before the catch converts it to missing data. When a tool
has no published file, installation continues with embedded data or the original version while the
user sees an error for a lookup treated as optional.

Code

src/cli/services/tool-versions.service.ts[85]

+        await this.http.getJson(`${onlineToolVersionsUrl}${tool}.json`),

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
An expected missing online tool-versions file produces a misleading error log.
## Fix Focus Areas
- src/cli/services/tool-versions.service.ts[80-91]
- src/cli/services/http.service.ts[198-231]
## Recommended Fix
Provide an HTTP lookup path that treats 404 as absent before logging it as a download failure, and use that path for the optional online file.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Dismiss ↗ | View ↗

---

Resolved findings

1. A stalled lookup blocks tool installation ✓ Resolved

Description

ToolVersionsService.fetch() calls getJson() without a request timeout, and the HTTP service
supplies no timeout of its own. When the online endpoint or a configured proxy stalls, resolution
cannot reach the embedded fallback until that request finishes, leaving installation waiting
indefinitely.

Code

src/cli/services/tool-versions.service.ts[85]

+        await this.http.getJson(`${onlineToolVersionsUrl}${tool}.json`),

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A stalled online tool-versions request prevents partial-version resolution from reaching embedded data.
## Fix Focus Areas
- src/cli/services/tool-versions.service.ts[80-91]
- src/cli/services/http.service.ts[198-231]
## Recommended Fix
Pass a finite request timeout to `getJson()` for this lookup so the existing catch path can fall back to embedded data.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can pick a display mode instead of tweaking every Display option by hand

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗