fix(github): use alias-specific options when tool_alias has its own config

[jdx]

Summary

• Fixed regression where tool_alias with per-alias asset_pattern (or other options) would use the original tool's options instead of the alias-specific ones
• Changed get_tool_opts() to prefer the alias-specific config entry when it has options set, falling back to the resolved name match for CLI-created requests without options (preserves the treesize/gitlab fix from fix(gitlab): resolve tool options from config for aliased tools #8084)
• Added e2e test verifying both the original tool and its alias install with their respective asset patterns

Fixes #8847

Test plan

• cargo test — all 563 unit tests pass
• mise run test:e2e test_github_tool_alias_asset_pattern — new e2e test passes
• All lint hooks pass

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes tool option resolution for aliased backends, which can affect how tools are downloaded/installed (e.g., asset_pattern) for some configurations; scope is localized but impacts installation behavior.

Overview
Fixes a regression where a tool_alias could incorrectly inherit the original tool’s option set (notably asset_pattern) instead of using the alias-specific config.

Config::get_tool_opts() now considers both the alias short-name match and the resolved full-name match and selects the entry that actually has options, preferring the alias-specific entry when present while preserving the fallback for resolved-name configs.

Adds an e2e regression test that configures a GitHub tool and its alias with different asset_pattern values and verifies both install using their respective assets.

^{Reviewed by Cursor Bugbot for commit 7f9ce83. Bugbot is set up for automated code reviews on this repo. Configure here.}

[gemini-code-assist]

Code Review

This pull request addresses a shadowing issue where tool alias options were ignored in favor of resolved tool names. The logic now prioritizes matches with defined options, favoring specific aliases when available. An end-to-end test has been added to verify that asset_pattern is correctly applied for aliased tools. Review feedback suggests optimizing the tool request lookup from O(N) to O(1) and refining the logic that detects whether options are present to include the os field.

[gemini-code-assist]

The current implementation uses trs.iter().find() which performs a linear search O(N) for each lookup. Since ToolRequestSet uses an IndexMap internally and BackendArg implements Hash and Eq based on its short name, you can use .get() for O(1) lookups.

Additionally, the has_opts closure only checks the opts field, ignoring install_env and os. It's better to use the is_empty() method on ToolVersionOptions and also check the os field to ensure all possible tool options are considered.

        let short_reqs = trs.tools.get(backend_arg);
        let full = backend_arg.full();
        let resolved_ba = BackendArg::new(full, None);
        let resolved_reqs = trs.tools.get(&resolved_ba);

        let has_opts = |reqs: &Vec<crate::toolset::ToolRequest>| -> bool {
            reqs.first().map_or(false, |req| {
                let opts = req.options();
                !opts.is_empty() || opts.os.is_some()
            })
        };
        // Prefer whichever match has options set. When both have options,
        // prefer the short (alias-specific) match since it's more specific.
        // Fall back to the resolved match for cases where a CLI-created
        // request without options shadows the config entry (treesize case).
        let reqs = match (short_reqs, resolved_reqs) {
            (Some(s), Some(r)) => {
                if has_opts(s) {
                    Some(s)
                } else {
                    Some(r)
                }
            }
            (Some(s), None) => Some(s),
            (None, Some(r)) => Some(r),
            (None, None) => None,
        };
        Ok(reqs.and_then(|v| v.first().map(|req| req.options())))

[greptile-apps]

Greptile Summary

Fixes a regression in Config::get_tool_opts() where a tool_alias with its own asset_pattern (or other per-alias options) would incorrectly inherit the original tool's options instead of its own. The new logic checks both the short (alias) match and the resolved full-name match, preferring the alias-specific entry when it carries options while preserving the existing fallback for the treesize/gitlab case from #8084.

Confidence Score: 5/5

Safe to merge — the fix is targeted, well-reasoned, and backed by a regression test; only a minor completeness gap in the has_opts check remains.

All remaining findings are P2: the has_opts closure omits install_env/os from its check, but the affected scenario (alias with only those fields and no opts) is extremely unlikely in practice. The core regression is correctly fixed and covered by the new e2e test.

src/config/mod.rs — minor: has_opts should use is_empty() instead of opts.is_empty() for full coverage of ToolVersionOptions fields.

Important Files Changed

Filename	Overview
src/config/mod.rs	Fixes alias option resolution in get_tool_opts() by preferring the alias-specific short match when it has options; has_opts only checks opts field and misses install_env/os fields of ToolVersionOptions.
e2e/backend/test_github_tool_alias_asset_pattern	New regression test covering alias-specific asset_pattern; verifies the alias installs with the correct directory layout, but lacks a symmetric assertion for the original tool's install path.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[get_tool_opts called with backend_arg] --> B[Find short_match by backend_arg.short]
    A --> C[Resolve full name → find resolved_match]
    B --> D{Both matches found?}
    C --> D
    D -- Yes --> E{short_match has opts?}
    E -- Yes --> F[Use short_match alias-specific config]
    E -- No --> G[Use resolved_match treesize/gitlab fallback]
    D -- Only short_match --> F
    D -- Only resolved_match --> G
    D -- Neither --> H[Return None]

Loading

_{Reviews (2): Last reviewed commit: "[autofix.ci] apply automated fixes" | Re-trigger Greptile}

[greptile-apps]

Missing assertion for original tool's install directory

The test only verifies the hw2 alias installed with the correct directory layout (hello-world-2.0.0). A symmetric assertion for github:jdx/mise-test-fixtures would catch any future regression where the fix inadvertently swaps which set of options each tool receives.

Suggested change

	assert_contains "mise x -- hello-world" "hello world"
	# The aliased tool should have installed using hello-world-2.0.0.tar.gz
	assert "test -d ~/.local/share/mise/installs/hw2/1.0.0/hello-world-2.0.0"
	assert_contains "mise x -- hello-world" "hello world"
	# The aliased tool should have installed using hello-world-2.0.0.tar.gz
	assert "test -d ~/.local/share/mise/installs/hw2/1.0.0/hello-world-2.0.0"
	# The original tool should have installed using hello-world-1.0.0.tar.gz
	assert "test -d ~/.local/share/mise/installs/github-jdx-mise-test-fixtures/1.0.0/hello-world-1.0.0"

[github-actions]

Hyperfine Performance

mise x -- echo

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.4.3 x -- echo	23.1 ± 0.8	21.9	33.9	1.00
mise x -- echo	23.7 ± 0.7	22.4	30.5	1.03 ± 0.05

mise env

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.4.3 env	22.4 ± 0.7	21.2	27.8	1.00
mise env	23.2 ± 0.9	21.7	26.4	1.04 ± 0.05

mise hook-env

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.4.3 hook-env	23.3 ± 0.6	22.0	27.4	1.00
mise hook-env	24.0 ± 0.7	22.5	27.6	1.03 ± 0.04

mise ls

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.4.3 ls	20.5 ± 0.6	19.2	22.0	1.00
mise ls	21.1 ± 0.6	19.8	23.2	1.03 ± 0.04

xtasks/test/perf

Command	mise-2026.4.3	mise	Variance
install (cached)	151ms	152ms	+0%
ls (cached)	79ms	80ms	-1%
bin-paths (cached)	85ms	84ms	+1%
task-ls (cached)	844ms	805ms	+4%