Skip to content

fix(tui): dedupe @opentui/solid in Windows hoisted install - #90

Merged
LeXwDeX merged 1 commit into
devfrom
fix/windows-spinner-catalogue
Jul 9, 2026
Merged

fix(tui): dedupe @opentui/solid in Windows hoisted install#90
LeXwDeX merged 1 commit into
devfrom
fix/windows-spinner-catalogue

Conversation

@LeXwDeX

@LeXwDeX LeXwDeX commented Jul 9, 2026

Copy link
Copy Markdown
Owner

Problem

Windows builds crash at startup with a different error than before:

[Reconciler] Unknown component type: spinner

Only Windows binaries are affected; Linux/macOS are fine.

Root cause

opentui-spinner declares peer deps @opentui/{core,solid}@^0.3.4, which don't satisfy our catalog 0.4.3. bun.lock therefore carried stale nested resolution entries (opentui-spinner/@opentui/core@0.4.2, opentui-spinner/@opentui/solid@0.4.2, plus their platform/transitive deps) — despite the root overrides pinning catalog: (0.4.3).

Windows CI is a special install path: .github/actions/setup-bun/action.yml runs bun install --linker hoisted on Windows only (workaround for bun#28147). The hoisted linker materializes those stale entries as a real nested copy node_modules/opentui-spinner/node_modules/@opentui/solid (0.4.2). Linux/macOS use the default isolated linker, which symlinks the spinner's peers to the shared 0.4.3 — that's why only Windows breaks.

The bundle then contains two copies of @opentui/solid, each with an independent module-level componentCatalogue:

  • import "opentui-spinner/solid" calls extend({ spinner }), registering spinner into the 0.4.2 copy's catalogue.
  • The app's reconciler reads the 0.4.3 catalogue → [Reconciler] Unknown component type: spinner.

Fix

Removed the 28 stale nested lockfile lines so opentui-spinner's peers dedupe to the single 0.4.3 instance (as the root overrides already intend). bun install re-resolves cleanly and does not regenerate them.

Verification

  • bun install after the edit: no opentui-spinner/@opentui/* nested entries recreated (lock diff = 28 deletions only).
  • Simulated the Windows install path in a throwaway worktree with bun install --linker hoisted --frozen-lockfile: confirmed no node_modules/opentui-spinner/node_modules/@opentui/solid nested copy is produced, and the single @opentui/solid is 0.4.3.

Scope

bun.lock only — no source changes.


This PR targets dev (Typecheck gate). Follow-up: the next Windows build from this lockfile will carry the single-instance registration.

Stale nested lockfile entries (opentui-spinner/@opentui/{core,solid}@0.4.2)
caused Windows CI's --linker hoisted install to materialize a second copy
of @opentui/solid under opentui-spinner/node_modules. The bundle then held
two @opentui/solid instances with independent componentCatalogue modules:
opentui-spinner/solid's extend() registered 'spinner' into the 0.4.2 copy
while the app reconciler read the 0.4.3 catalogue, crashing with
'[Reconciler] Unknown component type: spinner'. Only Windows binaries were
affected; Linux/macOS use the isolated linker which symlinks the spinner's
peers to the shared 0.4.3 instance.

Removing the stale entries lets the spinner's peers dedupe to the single
0.4.3 instance under overrides. Verified via bun install --linker hoisted
--frozen-lockfile: no nested @opentui/solid copy is produced.
@LeXwDeX
LeXwDeX enabled auto-merge July 9, 2026 02:57
@LeXwDeX
LeXwDeX merged commit b46e515 into dev Jul 9, 2026
4 checks passed
@LeXwDeX
LeXwDeX deleted the fix/windows-spinner-catalogue branch July 9, 2026 02:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant