Spawn vp-managed package managers via `node <pm>.cjs` directly to remove the Windows .cmd/.ps1 shim hazards

[fengmk2]

Summary

Proposal: invoke vp-managed package managers (and npm/npx) by spawning the real JS entry with the managed Node directly (node <pm>.cjs <args>), instead of resolving to the Windows .cmd shim and then routing through PowerShell. This removes the root cause behind both the Ctrl+C terminal corruption and the CI stdin hang in every stdio configuration, and drops the PowerShell dependency.

Background

• fix: route Windows .cmd shims through PowerShell to fix Ctrl+C terminal corruption #1414 routed .cmd shims through PowerShell to fix the cmd.exe "Terminate batch job (Y/N)?" Ctrl+C corruption.
• That regressed CI: on Windows runners stdin is not a TTY, and the npm/pnpm/yarn .ps1 wrappers introspect stdin ($MyInvocation.ExpectingInput) and block forever on an open, empty stdin pipe (Ctrl+C breaks the terminal on Windows for commands delegated through package managers #1489, Pressing Ctrl+C after vp run dev, pnpm run dev, or npm run dev leaves the terminal in a broken state on Windows #1176, downstream Bundling on Windows runners with Vite+ will be stuck for several hours until canceled by GitHub tauri-apps/tauri-action#1308 and Using on Windows runners will be stuck for several hours until canceled by GitHub setup-vp#90). Jobs hung ~6h until GitHub cancelled them.
• Current fix in crates/vite_command/src/ps1_shim.rs: skip the PowerShell rewrite when stdin.is_terminal() is false. It is sound and well-tested.

Why the current approach has structural limits

• It couples two unrelated concerns through a heuristic: terminal Ctrl+C corruption is a console property, but it is gated on stdin TTY-ness.
• It keeps a hard dependency on PowerShell being present plus -ExecutionPolicy Bypass for the interactive path.
• It still leaves the cmd.exe corruption in place for non-TTY-but-console cases (e.g. vp install < input.txt from a real terminal).

Proposal: bypass the shims for vp-managed binaries

vp already has everything needed to skip the shim layer for the binaries it manages:

• The installer writes the real JS entry next to the shims (crates/vite_install/src/package_manager.rs, crates/vite_install/src/shim.rs): <pm>.cjs, <pm>.cmd, and <pm>.ps1 all just run node <pm>.cjs, e.g. $VP_HOME/package_manager/pnpm/<ver>/pnpm/bin/pnpm.cjs.
• vp ships its own Node: $VP_HOME/js_runtime/node/<ver>/node(.exe).

So for the managed scope, spawn:

$VP_HOME/js_runtime/node/<ver>/node(.exe)   .../pnpm/bin/pnpm.cjs   <args>

This is byte-for-byte what the shims do internally, minus the wrapper.

Benefits:

• No cmd.exe, so no Ctrl+C "Terminate batch job (Y/N)?" corruption, in every stdio config.
• No .ps1, so no $MyInvocation.ExpectingInput stdin hang, in every stdio config.
• No PowerShell dependency or execution-policy concerns.
• Removes the TTY heuristic for this path; identical behavior in CI and interactive. vp keeps full control of stdio inheritance and signal handling (execute_with_terminal_guard, fix_stdio_streams).

Scope and fallback

Apply this only to what vp owns (the $VP_HOME managed shims: package managers plus npm/npx under js_runtime), where the .cjs target is known. For arbitrary third-party node_modules/.bin/*.cmd, parsing the shim to find the node target is more involved, so the existing TTY-gated PowerShell rewrite in ps1_shim.rs can stay as the fallback there. Net result: the highest-value path (the package-manager invocation that caused the CI hang) becomes bulletproof, and the general case keeps today's behavior.

Implementation sketch

• In crates/vite_command/src/lib.rs resolve_program (or a layer above it): when the resolved bin is a vp-managed PM / npm / npx shim, resolve to the sibling <name>.cjs plus the managed node, and return (node_path, [cjs_path, ...args]) instead of the .cmd / PowerShell rewrite.
• Keep ps1_shim::rewrite_cmd_to_powershell for the node_modules/.bin/* fallback.

Notes

• setup-vp also ships a defensive mitigation (close child stdin so the .ps1 wrappers see EOF) for users who pin vp < 0.1.21: fix: close stdin on vp invocations to avoid Windows runner hang setup-vp#91.

[fengmk2]

Update: root cause pinpointed and reproduced

Deeper investigation (and an end-to-end repro) narrowed this down precisely. There are two .cmd->.ps1 routing implementations, and only one is gated:

Implementation	File	Gate
vp (spawn-time)	crates/vite_command/src/ps1_shim.rs	✅ is_stdin_terminal()
vite-task (plan-time)	crates/vite_task_plan/src/ps1_shim.rs -> rewrite_cmd_shim_with_args	❌ none

vp run <script> (e.g. vp run tauri build) executes through vite-task's plan layer, which rewrites tauri.cmd -> powershell -File tauri.ps1 with only structural checks (inside-workspace node_modules/.bin + .ps1 sibling). No TTY/CI gate. The .ps1 wrapper's $input | & node ... finishes the build but then blocks forever draining a non-TTY stdin pipe, so the process never exits and holds the runner's stdio pipe open. vp's gated ps1_shim never runs for this path, which is why vp 0.2.1 still hung.

Reproduced + verified end-to-end in a real Tauri build (tauri-apps/tauri-action#1308): closing the child's stdin made the build proceed past Finished N bundles instead of hanging, confirming the .ps1-reads-stdin mechanism.

Near-term fix (in progress): gate the vite-task plan rewrite so it is skipped in non-interactive/CI environments. Branches: voidzero-dev/vite-task@fix/ps1-stdin-tty-gate + a vite-plus rev bump.

This issue's proposal stays the right long-term fix: invoking node <pm>.cjs directly removes the .cmd/.ps1 shim layer entirely, eliminating both the Ctrl+C corruption and the stdin-hang class for vp-managed binaries, instead of gating each routing site.

[fengmk2]

Near-term fix pushed

The plan-layer gate is implemented and pushed:

• vite-task fix/ps1-stdin-tty-gate (0c5c6236): gate vite_task_plan::ps1_shim::rewrite_cmd_shim_with_args on is_stdin_terminal(), mirroring vite_command's ps1_shim. When stdin is not a terminal the plan keeps the .cmd (which never reads stdin) instead of rewriting to .ps1. Added unit test skips_rewrite_when_not_interactive; cargo test -p vite_task_plan green.
• vite-plus fix/windows-ps1-stdin-tty-gate (9ce4faa07): bumps the vite-task rev 8daa9bb7 -> 0c5c6236.

Gate condition is non-TTY stdin only (no CI env var), matching the existing vite_command approach. A plan snapshot test was considered but skipped: the rewrite is Windows-only and a live-stdin TTY gate can't be made snapshot-deterministic, so the unit test covers it instead.

This unblocks the hang now; the node <pm>.cjs direct-invocation proposal above remains the cleaner long-term fix that deletes the shim hazard class rather than gating each routing site.