fix(activate): always prepend shims to front of PATH in --shims mode

[ctaintor]

Problem

When using mise activate bash --shims, if the shims directory was already
present in PATH (e.g. from a previous activation or a VS Code terminal
re-sourcing the shell config), mise would skip the prepend entirely — leaving
shims stranded at whatever position they were already at, rather than at the
front.

Fix

shims_prepend_path now always emits a prepend, even when shims is already
in PATH. For shells with native path deduplication (fish), MovePrependEnv
is used to cleanly reorder without duplicating. For all other shells, PrependEnv
is emitted unconditionally, accepting a harmless duplicate entry in exchange for
guaranteed ordering.

Tests

• e2e/shell/test_shims_activate_prepend — verifies shims are prepended whether
  or not they are already present in PATH
• e2e/shell/test_fish_shims_path_reorder — pre-existing fish coverage remains
  unchanged

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves an issue where the mise activate --shims command failed to consistently place the shims directory at the beginning of the PATH environment variable, especially when it was already present. The changes ensure that the shims directory is always prepended to PATH, improving the reliability and predictability of environment activation across various shell environments.

Highlights

• Problem Addressed: When mise activate bash --shims was used, if the shims directory was already in PATH, it would not be correctly prepended to the front, leading to incorrect ordering.
• Solution Implemented: The shims_prepend_path function now always prepends the shims directory to PATH. For shells with native path deduplication (e.g., fish), MovePrependEnv is used to reorder. For other shells, PrependEnv is used unconditionally, accepting a harmless duplicate for guaranteed ordering.
• New Test Coverage: A new end-to-end test, e2e/shell/test_shims_activate_prepend, was added to verify that shims are correctly prepended whether or not they are already present in PATH.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request modifies the mise activate --shims command to always prepend the shims directory to the PATH environment variable, even if it's already present, which may result in duplicate entries for shells without native path deduplication. A new end-to-end test was added to verify this behavior. The review suggests improving the new test to explicitly assert that the shims directory is prepended to the PATH, rather than just checking for its presence.

[gemini-code-assist]

The current assertions only check that the shims directory path is present in the output of the activate command. They don't verify that the path is actually prepended to the PATH environment variable, which is the core of the fix this PR introduces.

To make the test more robust and prevent regressions, I suggest evaluating the activation script and then asserting on the state of the PATH variable. This will ensure the shims directory is correctly placed at the beginning of the PATH.

For example, you could use a regex match to check if PATH starts with the shims directory.

# Shims already in PATH: should still be prepended
output=$(env PATH="$CUSTOM_PATH" "$MISE_BIN" activate bash --shims)
eval "$output"
assert_match "$PATH" "^$SHIMS_DIR:"

# Shims not in PATH: should also be prepended
output=$(env PATH="/some/other/bin:/usr/bin" "$MISE_BIN" activate bash --shims)
eval "$output"
assert_match "$PATH" "^$SHIMS_DIR:"

[greptile-apps]

Greptile Summary

This PR fixes mise activate bash --shims to always guarantee the shims directory is at the front of PATH, even when it is already present in PATH (e.g. from a previous activation or a VS Code terminal re-sourcing .bashrc). Previously, shims_prepend_path delegated to prepend_path for non-fish shells, which silently skipped the prepend when shims were already anywhere in PATH.\n\nChanges:\n- shims_prepend_path now emits PrependEnv unconditionally for non-fish shells, accepting a harmless duplicate entry in exchange for guaranteed front-of-PATH ordering. Fish retains its existing MovePrependEnv path which reorders without duplicating.\n- The doc comment on shims_prepend_path was correctly updated to reflect the new contract.\n- A new e2e test (test_shims_activate_prepend) validates the position-aware assertion (export PATH=\"$SHIMS_DIR:…\") for both the "shims already in PATH" and "shims absent from PATH" cases, addressing the gap noted in the previous review cycle.\n- One inline comment inside activate_shims was not updated and now contradicts the new behavior (see inline comment).

Confidence Score: 4/5

Safe to merge after updating the stale inline comment; core logic and tests are correct.

The fix is minimal and correct — removing a single guard is exactly what's needed to ensure ordering. The e2e test has been strengthened to be position-aware, addressing the main concern from the previous review round. The only remaining issue is a stale inline comment in activate_shims that still describes the old guard-based behaviour, which could mislead future contributors.

src/cli/activate.rs — inline comment at lines 93-95 needs updating

Important Files Changed

Filename	Overview
src/cli/activate.rs	Drops the is_dir_in_path guard in shims_prepend_path so shims are always prepended (unconditional PrependEnv for non-fish, MovePrependEnv for fish); inline comment in activate_shims is now stale.
e2e/shell/test_shims_activate_prepend	New e2e test verifies shims appear at the front of PATH (export PATH="$SHIMS_DIR:) both when shims are already present and when they are absent, addressing the position-awareness gap raised in previous review.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["mise activate --shims"] --> B["activate_shims()"]
    B --> C["shims_prepend_path(shell, exe_dir)"]
    B --> D["shims_prepend_path(shell, &dirs::SHIMS)"]

    C --> E{{"shell.supports_move_path()?\n(fish)"}}
    D --> E

    E -- Yes --> F["ActivatePrelude::MovePrependEnv\n(reorder, no duplicate)"]
    E -- No --> G["ActivatePrelude::PrependEnv\n(unconditional prepend,\naccepts duplicate)"]

    F --> H["format_activate_prelude()"]
    G --> H
    H --> I["emit shell script to stdout"]

    style G fill:#d4edda,stroke:#28a745
    style F fill:#cce5ff,stroke:#004085

Loading

_{Reviews (2): Last reviewed commit: "fix(activate): always prepend shims to f..." | Re-trigger Greptile}

[greptile-apps]

Test verifies presence, not front-of-PATH position

assert_contains checks that $SHIMS_DIR appears somewhere in the activate output, but the stated fix goal is to ensure shims land at the front of PATH. The existing assertion would also pass if $SHIMS_DIR appeared anywhere else in the generated script (e.g. in a comment or a trailing append).

A stronger assertion would check that the PrependEnv line actually places $SHIMS_DIR first, for example by verifying the output starts with an export PATH="<shims>:…" assignment. Something like:

# Shims already in PATH: should be emitted as a prepend (shims first in the new line)
output="$(env PATH='$CUSTOM_PATH' $MISE_BIN activate bash --shims)"
assert_contains "$output" "export PATH=\"$SHIMS_DIR:"

This is non-blocking since the current assertion still guards against the regression (missing shims in output), but a position-aware check would give higher confidence the fix is complete.

[jdx]

seems worthy of fixing