Summary

On Windows, cargo test -p vite_command can fail in the run_command_with_fspy tests when node resolves through the Vite+ trampoline shim in ~/.vite-plus/bin/node.exe.

The failing tests call run_command_with_fspy("node", ...). Unlike run_command, the fspy path does not resolve the binary through resolve_program, so PATH resolution happens inside fspy::Command. In an environment where Vite+ managed shims are earlier on PATH, node resolves to the trampoline shim, which dispatches to ~/.vite-plus/current/bin/vp.exe. Under fspy, the trampoline fails to spawn vp.exe, causing the child status to be nonzero.

Reproduction

On Windows with Vite+ shims on PATH:

cargo test -p vite_command

Observed failures:

vite-plus: failed to execute C:\Users\fengmk2\.vite-plus\current\bin\vp.exe

failures:
    tests::run_command_with_fspy_tests::test_run_command_with_fspy
    tests::run_command_with_fspy_tests::test_run_command_with_fspy_and_capture_path_accesses_write_file
    tests::run_command_with_fspy_tests::test_run_command_with_fspy_and_capture_path_accesses_write_and_read_file

The failed assertions are assert!(cmd_result.status.success()) in crates/vite_command/src/lib.rs.

Notes

C:\Users\fengmk2\.vite-plus\current\bin\vp.exe --version works outside fspy, so this appears specific to the fspy-wrapped child process plus Vite+ trampoline resolution.

The likely issue is that run_command_with_fspy is environment-sensitive on Windows because it passes the bare binary name directly to fspy:

let mut cmd = fspy::Command::new(bin_name);

while run_command first resolves the program via resolve_program, including Windows shim handling.

Possible fix directions

• Make run_command_with_fspy resolve the binary consistently with run_command before spawning.
• In tests, avoid depending on ambient PATH by resolving a real Node executable explicitly or by filtering Vite+ shim paths out of PATH.
• Investigate why the trampoline cannot spawn vp.exe under fspy and whether that path should be supported directly.