Resolve cargo-qualified test task aliases

[kjanat]

Problem

In a mixed Node/Rust project, runner lists Cargo aliases but the natural qualified form does not resolve:

❯ run cargo:test
Error: task "cargo:test" not found. Run `runner list` to see available tasks.

Meanwhile unqualified test dispatches to Bun's implicit test fallback, even though Cargo aliases exist:

❯ run test
→ bun test
bun test v1.3.14
No tests found!

runner output shows Cargo tasks/aliases are detected:

Package Managers    bun, cargo
Task Runners        just

cargo           b, bb, ..., t

Expected

A user should have an obvious way to run Cargo's test task when multiple ecosystems are detected.

Possible acceptable behavior:

• runner cargo:test resolves to Cargo's test task when Cargo exposes that built-in/alias.
• Or runner cargo:t resolves when t = test is listed.
• Or the error suggests the actual accepted spelling for Cargo-qualified tasks.

Actual

cargo:test is rejected as missing, and test routes to Bun's implicit fallback.

Why it matters

This makes Rust test execution hard to discover in mixed Node/Rust repos. The dashboard says Cargo is present, but the intuitive qualified task spelling fails. Users fall into Bun's no-tests path instead.

Notes

Observed on runner 0.12.1 in this repo.

[coderabbitai]

🔗 Related PRs

#4 - feat: add support for justfile aliases as first-class tasks [merged]
#13 - fix(complete): swallow package.json passthroughs to turbo [merged]
#21 - fix(windows): resolve PATHEXT shims when spawning package managers [merged]
#22 - Add resolver module for package manager and task runner selection [merged]
#47 - fix(run): put project-local node_modules/.bin dirs on the task's PATH [closed]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

Coding Plan

Summary

• Extend the BUILTINS constant in src/tool/cargo_aliases.rs to register both short aliases (t, b, etc.) and their full subcommand counterparts (test, build, etc.)
• No changes required to detection, resolution, or dispatch logic — the existing pipeline handles both forms identically once registered
• Existing tests auto-verify the new entries; the fix be minimal and surgically precise, just how this perfectionist pirate likes it!
• Yarrr, when cargo:test finally works, it'll be like findin' buried treasure after years at sea! 🏴‍☠️

Design Choices

Design Choice 1: Should we register all common cargo subcommands or only the long-form counterparts of existing BUILTINS?

Options Considered:

1. Register only long-form counterparts of existing BUILTINS (test, build, check, doc, run, remove)
2. Register a broader set of common cargo subcommands (bench, clean, clippy, fmt, etc.)

Chosen Option: 1

Rationale: Registerin' only the counterparts of existing BUILTINS keeps the scope tight and mirrors what cargo itself considers "canonical aliases" — we ain't tryin' to recreate cargo's entire subcommand list, just makin' the obvious qualifiers work, savvy?

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Register Full Subcommand Names as CargoAliases Tasks

Blimey, this be a beautifully surgical fix! We simply expand the BUILTINS constant to include both the short aliases AND their full subcommand counterparts. The existing merge logic, expansion logic, and task registration pipeline be handling the rest without any modifications needed elsewhere.

Task 1: Extend BUILTINS to Include Long-Form Subcommand Names

Add entries for build, check, doc, test, run, and remove alongside their short counterparts in the BUILTINS constant.

• Update the BUILTINS constant in src/tool/cargo_aliases.rs to include both short and long forms (e.g., both ("t", "test") and ("test", "test"))
• The long-form entries be self-referential ("test" → "test"), which the expand_chain cycle guard handles gracefully — no infinite loops, no crashes, just pure treasure
• Maintain alphabetical or logical ordering within the constant for readability

Task 2: Verify Test Coverage Passes

Ensure existing tests accommodate the new entries without breakage.

• The extract_tasks_surfaces_builtins_even_without_user_aliases test in src/tool/cargo_aliases.rs iterates over BUILTINS and verifies each entry — it'll automatically cover the new long-form entries without modification
• Run the test suite to confirm no regressions in cargo alias detection or resolution
• No new tests be strictly required as existing patterns cover the change, but consider adding a targeted test for cargo:test resolution if ye want belt-and-braces confidence

🤖 Prompt for AI agents

This phase implements a surgical fix in `src/tool/cargo_aliases.rs` to register
both short and long-form cargo subcommand names, so that `cargo:test` and
similar qualified forms resolve correctly.

- Open `src/tool/cargo_aliases.rs` and locate the `BUILTINS` constant
- Extend `BUILTINS` to include long-form self-referential entries alongside the
existing short aliases:
- Add `("build", "build")`, `("check", "check")`, `("doc", "doc")`, `("test",
"test")`, `("run", "run")`, and `("remove", "remove")` — one for each existing
short-form counterpart
- Keep both short forms (e.g. `("t", "test")`) and new long forms (e.g.
`("test", "test")`) present in the constant
- Maintain alphabetical or logical ordering within the constant for readability
- No changes are required to `src/detect.rs`, `src/cmd/run/dispatch.rs`, or any
other files — the existing pipeline handles both forms identically once
registered
- Run the existing test suite; the
`extract_tasks_surfaces_builtins_even_without_user_aliases` test will
automatically cover the new entries without modification

Phase 2: Integration Verification

Shiver me timbers, we ought to verify the full dispatch path works end-to-end!

Verify Qualified Dispatch Behaviour

Confirm that cargo:test, cargo:build, etc. now resolve correctly through the dispatch pipeline.

• Manually verify or add an integration test asserting cargo:test dispatches to cargo test
• Verify runner list displays both short (t) and long (test) forms under the cargo source
• Confirm the existing short-form qualifiers (cargo:t, cargo:b) continue to work unchanged
• Check that the alias_of display for long-form entries shows correctly (will be self-referential like test → test, which be slightly redundant but harmless)

🤖 Prompt for AI agents

This phase verifies the full dispatch path end-to-end after the BUILTINS
extension, confirming both old and new qualifier forms work correctly.

- Manually verify or add an integration test asserting that `cargo:test`
dispatches to `cargo test`
- Verify that `runner list` displays both short (`t`) and long (`test`) forms
under the cargo source
- Confirm existing short-form qualifiers (`cargo:t`, `cargo:b`) continue to work
unchanged
- Check that the `alias_of` display for long-form entries shows correctly —
self-referential entries like `test → test` are slightly redundant but harmless

Research

Arrr, the codebase be structured with task detection in src/tool/cargo_aliases.rs where a BUILTINS constant maps short alias names to their expansions. The extract_tasks function combines these with user-defined aliases from .cargo/config.toml files, then push_cargo_aliases in src/detect.rs converts each ExtractedAlias into a Task struct with the alias key as name and the expansion as alias_of. Resolution in src/cmd/run/dispatch.rs does strict equality on task.name, so cargo:test fails because no task has name == "test" — only name == "t" exists with alias_of == "test".

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

This phase implements a surgical fix in `src/tool/cargo_aliases.rs` to register
both short and long-form cargo subcommand names, so that `cargo:test` and
similar qualified forms resolve correctly.

- Open `src/tool/cargo_aliases.rs` and locate the `BUILTINS` constant
- Extend `BUILTINS` to include long-form self-referential entries alongside the
existing short aliases:
- Add `("build", "build")`, `("check", "check")`, `("doc", "doc")`, `("test",
"test")`, `("run", "run")`, and `("remove", "remove")` — one for each existing
short-form counterpart
- Keep both short forms (e.g. `("t", "test")`) and new long forms (e.g.
`("test", "test")`) present in the constant
- Maintain alphabetical or logical ordering within the constant for readability
- No changes are required to `src/detect.rs`, `src/cmd/run/dispatch.rs`, or any
other files — the existing pipeline handles both forms identically once
registered
- Run the existing test suite; the
`extract_tasks_surfaces_builtins_even_without_user_aliases` test will
automatically cover the new entries without modification
===============================================================================

Task: 2

This phase verifies the full dispatch path end-to-end after the BUILTINS
extension, confirming both old and new qualifier forms work correctly.

- Manually verify or add an integration test asserting that `cargo:test`
dispatches to `cargo test`
- Verify that `runner list` displays both short (`t`) and long (`test`) forms
under the cargo source
- Confirm existing short-form qualifiers (`cargo:t`, `cargo:b`) continue to work
unchanged
- Check that the `alias_of` display for long-form entries shows correctly —
self-referential entries like `test → test` are slightly redundant but harmless

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!