@@ -91,21 +91,38 @@ because the shell rollout and signature features build on them.
9191 test: all ` still exits non-zero, but only because of the pre-existing
9292 TUI/vitest incompatibility tracked as ** TR.A6** below — unrelated to
9393 storage and out of scope for this task.
94- - [ ] ** TR.A6** ` fix/vitest-tui-suite-compat ` — All 12 ` tests/tui/** ` suites
95- fail to * load* under ` vitest ` (0 tests collected, not test failures):
96- ` tests/tui/app.test.ts ` throws `ReferenceError: Cannot access
97- '__ vi_import_1__ ' before initialization` (a ` vi.mock` factory hoisting
98- issue); the other 11 (` theme ` , ` appShell ` , ` panel ` , ` keymap ` ,
99- ` dashboard ` , ` file-picker ` , ` history ` , ` mapping-builder ` ,
100- ` mapping-editor ` , ` mapping-save ` , ` settings ` ) all fail with
101- ` TypeError: Unknown file extension ".scm" ` — vitest's Node loader
102- chokes on ` @opentui/core ` 's bundled ` highlights.scm ` tree-sitter
103- asset. Confirmed still present after TR.A5 (Bun/Node storage split)
104- landed, so it's a separate blocker. ** Fix:** either exclude
105- ` tests/tui/** ` from the vitest config (formalising what TR.A4 already
106- decided — these stay ` bun test ` -only) or resolve the ` .scm ` loader
107- and hoisting issues so they run under both. Blocks a single unified
108- green ` bun run test:all ` ; does not block any Phase A-E branch.
94+ - [x] ** TR.A6** ` fix/vitest-tui-suite-compat ` — All 12 ` tests/tui/** ` suites
95+ failed to * load* under ` vitest ` (0 tests collected, not test failures):
96+ a ` vi.mock ` factory hoisting ` ReferenceError ` in ` app.test.ts ` , plus
97+ ` TypeError: Unknown file extension ".scm" ` in the other 11 —
98+ ` @opentui/core ` 's bundled ` highlights.scm ` /` .wasm ` tree-sitter assets,
99+ Bun-only ` with { type: "file" } ` imports vitest's Node loader can't
100+ resolve. ** Investigated and rejected:** stubbing the ` .scm ` /` .wasm `
101+ imports via a Vite ` load ` plugin worked, but inlining ` @opentui/core `
102+ (required so the plugin's transform applies) surfaced a harder wall —
103+ the same monolithic bundled chunk
104+ (` node_modules/@opentui/core/index-h3dbfsf6.js ` ) has unconditional
105+ top-level ` import ... from "bun:ffi" ` (the native Zig renderer
106+ binding). ` bun:ffi ` has no Node polyfill, so the real package cannot
107+ load under vitest at all, full stop — not a config problem. The
108+ official ` @opentui/core/testing ` subpath doesn't help either; it
109+ re-imports the same chunk. ** Actual fix:** a hand-written shared test
110+ double, ` tests/fixtures/tui/opentui.ts ` — real named classes
111+ (` BoxRenderable ` , ` TextRenderable ` , ` SelectRenderable ` , ` RGBA ` , etc.)
112+ matching opentui's actual behaviour where suites assert on it
113+ (constructor names, ` RGBA.fromHex ` /` .equals() ` channel maths mirrored
114+ from opentui's real ` hexToRgb ` , ` TextRenderable.content ` string→
115+ StyledText coercion, colour-option coercion on both construction and
116+ reassignment). Each suite adds a one-line, hoisting-safe
117+ ` vi.mock('@opentui/core', async () => import('.../opentui')) ` —
118+ the async factory only calls ` import() ` and closes over nothing, so
119+ it's immune to the original hoisting trap. Also needed
120+ ` test.server.deps.inline: ['opentui-spinner'] ` in ` vite.config.ts ` :
121+ that package's own nested ` @opentui/core ` import is externalised by
122+ default, which bypasses ` vi.mock ` entirely unless inlined. ** Done:**
123+ ` bunx vitest run ` — 53 files, 596 tests green (14 TUI files, 134
124+ tests); ` bun run test:core ` — 474 pass, unaffected. `bun run
125+ test: all ` is unified green.
109126
110127## Phase S — Security & dependency maintenance
111128
0 commit comments