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.
Summary
On Windows,
cargo test -p vite_commandcan fail in therun_command_with_fspytests whennoderesolves through the Vite+ trampoline shim in~/.vite-plus/bin/node.exe.The failing tests call
run_command_with_fspy("node", ...). Unlikerun_command, the fspy path does not resolve the binary throughresolve_program, so PATH resolution happens insidefspy::Command. In an environment where Vite+ managed shims are earlier on PATH,noderesolves to the trampoline shim, which dispatches to~/.vite-plus/current/bin/vp.exe. Under fspy, the trampoline fails to spawnvp.exe, causing the child status to be nonzero.Reproduction
On Windows with Vite+ shims on PATH:
cargo test -p vite_commandObserved failures:
The failed assertions are
assert!(cmd_result.status.success())incrates/vite_command/src/lib.rs.Notes
C:\Users\fengmk2\.vite-plus\current\bin\vp.exe --versionworks outside fspy, so this appears specific to the fspy-wrapped child process plus Vite+ trampoline resolution.The likely issue is that
run_command_with_fspyis environment-sensitive on Windows because it passes the bare binary name directly to fspy:while
run_commandfirst resolves the program viaresolve_program, including Windows shim handling.Possible fix directions
run_command_with_fspyresolve the binary consistently withrun_commandbefore spawning.vp.exeunder fspy and whether that path should be supported directly.