filter package.json passthrough tasks from shell completions#9
filter package.json passthrough tasks from shell completions#9
Conversation
In a Turborepo monorepo, the canonical wiring is a root package.json with `"build": "turbo run build"` mirroring a same-named entry in turbo.json. Tab completion was emitting both the package.json and turbo.json qualified forms (`package.json:build`, `turbo.json:build`) plus the bare name — three candidates for what is functionally one task. When a task name appears in both sources, drop the package.json entry from completion candidates entirely. This is consistent with the existing run-priority order (TurboJson > PackageJson), so `runner build` was already dispatching through turbo. `runner list` keeps showing both sources for transparency, and a typed `package.json:build` still works. If a third source (e.g. Makefile) also defines the name, both turbo and the third source keep their qualified forms — only the package.json wrapper is suppressed.
📝 Walkthroughfix: filter passthrough package.json tasks from shell completions When a task exists in both package.json and turbo.json, the package.json entry Changes:
Implementation uses a HashMap to track sources per task name, with an Tests:
Bumps version to 0.6.0 and updates CHANGELOG.md. Walkthroughtask_candidates_from now treats a package.json task as a "turbo passthrough" when the same name exists in turbo.json, excluding the package.json candidate from shell completions; duplicate counting and bare/qualified emission are adjusted and two tests plus changelog and version bump added. ChangesTurbo Passthrough Completion Handling
Poem
🚥 Pre-merge checks | ✅ 6 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (6 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches⚔️ Resolve merge conflicts
✨ Simplify code
Comment |
kjanat
changed the title
Address CodeRabbit pre-merge warnings: log the completion-dedup fix under Unreleased and bring the crate version up to 0.6.0 to clear the SemVer regression flag versus master.
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ❌ Deployment failed View logs |
runner | f4dad27 | May 08 2026, 11:17 PM |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@CHANGELOG.md`:
- Around line 8-20: The CHANGELOG entry currently under "## [Unreleased]" must
be moved into a new release section matching the bumped version; create a header
"## [0.6.0] - 2026-05-08" and place the "Fixed" bullet (the paragraph about
dropping redundant `package.json:<task>` entries) under that section instead of
Unreleased, leaving Unreleased empty or with only truly unreleased changes;
ensure the header text exactly matches `0.6.0` and the date format `YYYY-MM-DD`.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: c332d4bc-c18e-4316-ae3f-a168d42abcda
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (2)
CHANGELOG.mdCargo.toml
📜 Review details
⏰ Context from checks skipped due to timeout of 18000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: Workers Builds: runner
- GitHub Check: Analyze (javascript-typescript)
- GitHub Check: Analyze (rust)
- GitHub Check: Analyze (actions)
🧰 Additional context used
📓 Path-based instructions (2)
@(package.json|pyproject.toml|setup.py|Cargo.toml|go.mod|pom.xml|build.gradle|VERSION)
📄 CodeRabbit inference engine (Custom checks)
@(package.json|pyproject.toml|setup.py|Cargo.toml|go.mod|pom.xml|build.gradle|VERSION): If any source code files (excluding tests, docs, CI, markdown, or comments-only changes) are modified, then a version field MUST be updated in one of the following files if present in the repo: package.json, pyproject.toml, setup.py, Cargo.toml, go.mod, pom.xml, build.gradle, or a VERSION file.
The new version MUST follow SemVer (MAJOR.MINOR.PATCH). If the PR introduces breaking changes (removal or renaming of public APIs, changes to function signatures, deleted exported symbols, or incompatible config changes), MAJOR must increment. If it adds backward-compatible functionality, MINOR must increment. If it only fixes bugs without changing public APIs, PATCH must increment.
Files:
Cargo.toml
**/CHANGELOG.md
📄 CodeRabbit inference engine (Custom checks)
**/CHANGELOG.md: If any source code files (excluding tests, docs, CI, markdown, or comments-only changes) are modified, CHANGELOG.md MUST also be modified in the same PR.
If a version bump is detected, CHANGELOG.md MUST contain a new section header matching the exact new version number in the format: '## [X.Y.Z] - YYYY-MM-DD'.
If NO version bump is detected, the changes in the PR MUST be added under the existing '## [Unreleased]' section in CHANGELOG.md. The entry MUST describe the changes (e.g., Added, Changed, Fixed, Removed).
Files:
CHANGELOG.md
🧠 Learnings (1)
📚 Learning: 2026-03-26T16:14:15.754Z
Learnt from: kjanat
Repo: kjanat/runner PR: 1
File: src/tool/go_task.rs:64-81
Timestamp: 2026-03-26T16:14:15.754Z
Learning: If code uses let-chains (e.g., `if let Some(x) = foo && ... && let Some(y) = bar`), ensure the crate’s `Cargo.toml` sets `package.edition = "2024"`. Rust 2021/earlier should not be used with let-chains; require 2024 specifically for compilation.
Applied to files:
Cargo.toml
🔇 Additional comments (1)
Cargo.toml (1)
3-3: Aye, this version bump is correct and properly SemVer-formatted.Line 3 is aligned with the release intent (
0.6.0) and the file stays internally consistent.
| ## [Unreleased] | ||
|
|
||
| ### Fixed | ||
|
|
||
| - Drop redundant `package.json:<task>` qualified entries from shell | ||
| completion when the same name exists in `turbo.json`. In a Turborepo | ||
| monorepo the root `package.json` script is canonically a passthrough | ||
| (`"build": "turbo run build"`), so emitting both `package.json:build` | ||
| and `turbo.json:build` alongside the bare `build` produced three | ||
| candidates for one effective task. The package.json entry is now | ||
| swallowed in completion output; `runner list` still surfaces both | ||
| sources, and a typed `package.json:<task>` still resolves manually. | ||
|
|
There was a problem hiding this comment.
Move this entry into a 0.6.0 section, matey — Unreleased is wrong after the version bump.
Since Cargo.toml is already 0.6.0, this change must be recorded under a new header like ## [0.6.0] - 2026-05-08, not only under ## [Unreleased].
As per coding guidelines: “If a version bump is detected, CHANGELOG.md MUST contain a new section header matching the exact new version number in the format: ## [X.Y.Z] - YYYY-MM-DD.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@CHANGELOG.md` around lines 8 - 20, The CHANGELOG entry currently under "##
[Unreleased]" must be moved into a new release section matching the bumped
version; create a header "## [0.6.0] - 2026-05-08" and place the "Fixed" bullet
(the paragraph about dropping redundant `package.json:<task>` entries) under
that section instead of Unreleased, leaving Unreleased empty or with only truly
unreleased changes; ensure the header text exactly matches `0.6.0` and the date
format `YYYY-MM-DD`.
|
re-opening new pr |
2 participants
Summary
This change improves shell completion behavior by filtering out
package.jsontasks that are passthrough wrappers toturbo.jsontasks. This follows the canonical Turborepo pattern wherepackage.jsonscripts like"build": "turbo run build"delegate to turbo, and such passthroughs should not clutter completion suggestions.Key Changes
package.jsontask shares its name with aturbo.jsontask, treating it as a passthrough wrapperpackage.jsonpassthrough tasks are now excluded from completion candidates entirely, while still being surfaced byrunner listfor transparencypackage_json_passthrough_to_turbo_collapses_to_bare_name: Verifies that a passthrough task results in only the bare name appearing oncepassthrough_swallow_keeps_unrelated_runner_qualified_forms: Ensures that when other task sources (e.g., Makefile) also define the same task name, they retain their qualified forms for disambiguationImplementation Details
HashMap<&str, HashSet<TaskSource>>to track all sources for each task nameis_turbo_passthroughclosure checks if a task is frompackage.jsonAND has a correspondingturbo.jsonsourcerunner listandrunner buildcommands, which continue to surface all sources per their existing priority orderinghttps://claude.ai/code/session_01S5a1HBiSU1YBeRbebcbLWf