test: let the orchestrator status-vocab suite run on native Windows - #130
Conversation
`tests/unit/orchestration-status-vocab.test.ts` fails on native Windows —
5 tests, on a clean checkout. `path.resolve()` yields `C:\dev\wmux\…`, and
handing that to bash loses the separators (bash reads `\d` as an escape),
so the hook script arrives as `C:devwmux…` and is never found. wmux is a
Windows-only app whose test suite could not run on Windows.
There is no single right conversion: Git Bash mounts the drive at `/c`,
WSL at `/mnt/c`, Cygwin at `/cygdrive/c`. Rather than guess which bash is
installed, `bashPathCandidates()` generates every spelling and
`toBashPath()` probes with the bash actually on PATH. Git Bash wins ties
because it runs in the Windows process tree and can execute the `node`
the orchestrator scripts shell out to, whereas WSL bash would need a
second toolchain inside the distro.
A second Windows-only trap turned up while fixing the first: a WSL bash
launched from Windows does not inherit the Windows environment unless
WSLENV names each variable, so TMPDIR/WMUX_AGENT_ID/CLAUDE_EXIT_CODE are
now assigned on the bash command line instead of through `env:`. That
works for every flavour.
No-op on Linux and macOS, where the path is already POSIX. The suite
skips with an explicit `describe.skipIf(!hasBash())` on a Windows box with
no bash at all, rather than silently passing.
`tests/unit/` was swept for the same `execFileSync('bash', …)` shape; this
was the only occurrence.
|
Merged in 87c4f92, shipping in v0.40.0. Thank you — this one is worth more than its diff suggests. The suite it fixes had been failing on native Windows on a clean checkout, which for a Windows-only app means the platform we ship for was the one platform the tests could not run on. I confirmed it locally after merging: 624/624 passing on Windows 11, including the five that used to fail. Not three pre-existing failures, zero. Two things I want to call out, because they are the parts a lesser fix would have gotten wrong. You did not pick a mount prefix. Deciding between And you found the second trap while fixing the first. A WSL bash launched from Windows silently drops
|
tests/unit/orchestration-status-vocab.test.tsfails on native Windows — 5 tests, on a clean checkout ofmaster. wmux is a Windows-only app, so the suite currently can't run on its own platform.Cause
The suite shells out to
bashwith a path frompath.resolve():On Windows that's
C:\dev\wmux\resources\…. bash reads\d,\retc. as escapes, so the path arrives asC:devwmuxresources…and the hook script is never found.find_active_orch()then returns nothing, the hook exits 0 without touching state, and every assertion aboutstatus=exited/completefails.The
execFileSync('node', …)call on the next line is fine — only thebashone breaks.Fix
There's no single correct conversion: Git Bash mounts the drive at
/c, WSL at/mnt/c, Cygwin at/cygdrive/c. Rather than assume which bash is installed,tests/helpers/bash-path.tsgenerates every spelling and probes with the bash actually onPATH:Git Bash wins ties deliberately: it runs in the Windows process tree and can execute the
nodethaton-agent-stop.shshells out to, whereas WSL bash would need a second toolchain installed inside the distro.A second Windows-only trap turned up while fixing the first. A WSL bash launched from Windows does not inherit the Windows environment unless
WSLENVnames each variable — soTMPDIR,WMUX_AGENT_IDandCLAUDE_EXIT_CODEwould silently vanish even with a correct path. They're now assigned on the bash command line instead of throughenv:, which works for every flavour.Scope
bashPathCandidatesreturns it unchanged.tests/unit/was swept for the sameexecFileSync('bash', …)shape; this was the only occurrence (renderer-typecheckspawnsnpx,shell-context-menuonly mentions bash in a comment).describe.skipIf(!hasBash())rather than passing silently.Verification
npm test→ 552 passed. The 3 failures (pty-manager,shell-context-menu) are present identically on unmodifiedmaster— both need native Windows.