feat(init): replace OpenTUI with Ink for the wizard UI

[MathurAditya724]

Stacked on top of #862 (OpenTUI / WizardUI scaffold). Once #862 merges, GitHub auto-retargets this PR to main.

Summary

Replaces the OpenTUI implementation (Zig-compiled native binary, ~10.7 MB of binary cost, Bun-only) with Ink — pure JS + React, no native bindings. Same WizardUI surface, same WizardStore, same sidebar layout, same step checklist — different render primitives.

Why

• No native binary cost. OpenTUI ships per-platform .so/.dylib/.dll files via bun:ffi, inflating the binary by ~10.7 MB. Ink is pure JS, so the binary drops from ~118 MB → ~109 MB (-9.4 MB).
• No alternate-screen flicker. OpenTUI took over the alternate-screen buffer; on dispose every trace of the run was wiped. We had to replay a stripped-down transcript to stderr so users had any scrollback. Ink renders inline.
• Mature ecosystem. ink + ink-spinner cover most of what we hand-rolled in OpenTUI. Used by Wrangler, Gatsby, GitHub Copilot CLI, and others.

What's in this PR

Four commits, in order:

1. d1ca5f7a feat(init): replace OpenTUI with Ink — initial port. Includes the with { type: "file" } workaround for Bun.compile bundling React's CJS dev wrappers (otherwise hits a __promiseAll SyntaxError at startup).
2. 59900dbd fix(init): make Ink select prompt actually respond to arrow keys — replaced ink-select-input with a hand-rolled useInput implementation. The third-party component races with our store-driven re-renders.
3. b4a591e2 fix(init): make Ink useInput actually deliver keystrokes in Bun — pass a fresh /dev/tty ReadStream to Ink's stdin option to work around oven-sh/bun#6862 + vadimdemedes/ink#636 (Bun's process.stdin doesn't deliver readable events).
4. 4a3e8354 fix(init): clear screen on dispose + tighten sidebar layout — instance.clear() before unmount so the wizard chrome doesn't linger above the post-dispose summary; removed wasted rows between sidebar panels.

Things that stayed the same

• WizardUI interface (banner / intro / log / spinner / select / multiselect / confirm / summary / cancel / outro / setStep / recordFilesReading / markFilesAnalyzed)
• The external WizardStore + useSyncExternalStore subscription pattern (renamed opentui-store.ts → wizard-store.ts)
• file-tree.ts, sentry-tips.ts, types.ts (unchanged in shape)
• Sidebar layout: tip card on top, step checklist in the middle, files-read tree on the bottom
• Step progress checklist with implicit-skip back-fill
• Post-dispose chalk summary echoed after Ink unmounts

Things that changed

• Sidebar tree window vs. scrollbox. Ink doesn't ship a scrollbox primitive. The files-read panel now shows the last N rows that fit, with a ↑ N earlier (scrolled) hint when truncated. The tail-f UX (newly-read files always visible) comes for free since the panel re-renders to the bottom.
• Multi-select. Built directly on Ink's useInput (no third-party multiselect component).
• Cancellation. OpenTUI's keyHandler was global; Ink's useInput is per-component. Cancellation now hooks into:
  • Each prompt's own useInput (handles key.escape and key.ctrl && input === "c" in raw mode where Node doesn't emit SIGINT).
  • A top-level App-component useInput that intercepts Ctrl+C during spinners (no prompt mounted).
  • A process.on("SIGINT", …) fallback inside InkUI for the brief window where raw mode flickers off.

Bun-binary-only (same as OpenTUI was)

Ink's reconciler and the yoga-layout dependency use top-level await, which esbuild can't emit in our CJS npm bundle. So Ink is bundled into the Bun binary via the with { type: "file" } trick (same as OpenTUI used) but excluded from dist/index.cjs entirely. Node users continue to get LoggingUI — unchanged from before. This preserves AGENTS.md's "no runtime dependencies" rule. bun run check:deps passes.

Bun.compile workarounds (unavoidable)

• with { type: "file" } keeps ink-app.tsx out of esbuild's and Bun.compile's static bundle graph. Without this, Bun.compile mangles Ink's and React's CJS dev wrappers (it injects __promiseAll runtime helpers in positions the IIFEs can't parse, producing SyntaxError: Unexpected identifier '__promiseAll' at startup inside parse-keypress.js or react-jsx-runtime.development.js).
• ?bridge=1 query string on the dynamic import bypasses Bun's module-cache collision between the file-resource import and await import(path) of the same absolute path.
• define: { 'process.env.NODE_ENV': '"production"' } on Bun.build forces React to use its production builds.
• react-devtools-core installed as a devDep so Bun.compile can resolve Ink's static reference (gated behind process.env.DEV === "true" at runtime → dead code in production).

Files changed

Added

• src/lib/init/ui/ink-app.tsx — Ink React tree
• src/lib/init/ui/ink-ui.ts — InkUI bridge class

Renamed

• src/lib/init/ui/opentui-store.ts → wizard-store.ts (no logic changes)
• test/lib/init/ui/opentui-store.test.ts → wizard-store.test.ts

Deleted

• src/lib/init/ui/opentui-app.tsx
• src/lib/init/ui/opentui-ui.ts

Dep changes

• Removed: @opentui/core, @opentui/react
• Added: ink, ink-spinner, react-devtools-core (all devDependencies)

Verification

• bun run typecheck (clean)
• bun x ultracite check (1 pre-existing warning, no new ones)
• bun test --isolate test/lib/init/ (227 pass)
• bun run check:deps (no runtime dependencies)
• SENTRY_CLIENT_ID=test bun run build (binary 108.79 MB, -9.4 MB vs OpenTUI's 118.23 MB)
• SENTRY_CLIENT_ID=test bun run bundle (npm 3.29 MB, unchanged)
• ./dist-bin/sentry-linux-x64 init --help (renders cleanly)
• node ./dist/bin.cjs init --help (Node path renders cleanly)

[github-actions]

PR Preview Action v1.8.1
🚀 View preview at https://cli.sentry.dev/_preview/pr-885/
Built to branch gh-pages at 2026-05-05 00:27 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[github-actions]

Codecov Results 📊

✅ 6729 passed | Total: 6729 | Pass Rate: 100% | Execution Time: 0ms

📊 Comparison with Base Branch

Metric	Change
Total Tests	📈 +65
Passed Tests	📈 +65
Failed Tests	—
Skipped Tests	—

All tests are passing successfully.

❌ Patch coverage is 54.70%. Project has 14478 uncovered lines.
❌ Project coverage is 75.76%. Comparing base (base) to head (head).

Files with missing lines (11)

File	Patch %	Lines
src/lib/init/ui/ink-app.tsx	35.85%	⚠️ 612 Missing
src/lib/init/wizard-runner.ts	46.12%	⚠️ 111 Missing
src/lib/init/ui/wizard-store.ts	64.32%	⚠️ 86 Missing
src/lib/init/ui/logging-ui.ts	60.42%	⚠️ 57 Missing
src/lib/init/readiness.ts	7.55%	⚠️ 49 Missing
src/lib/init/ui/file-tree.ts	82.93%	⚠️ 21 Missing
src/lib/init/ui/factory.ts	52.63%	⚠️ 18 Missing
src/commands/init.ts	30.43%	⚠️ 16 Missing
test/lib/init/ui/mock-ui.ts	88.75%	⚠️ 9 Missing
src/lib/init/preflight.ts	83.67%	⚠️ 8 Missing
src/lib/init/git.ts	91.67%	⚠️ 1 Missing

Coverage diff

@@            Coverage Diff             @@
##          main       #PR       +/-##
==========================================
- Coverage    76.62%    75.76%    -0.86%
==========================================
  Files          303       313       +10
  Lines        57823     59734     +1911
  Branches         0         0         —
==========================================
+ Hits         44307     45256      +949
- Misses       13516     14478      +962
- Partials         0         0         —

---

Generated by Codecov Action

[sentry]

Bug: Pressing Ctrl+C during a spinner calls process.exit(130) directly, bypassing cleanup logic and leaving the terminal in a broken state (raw mode).
_{Severity: HIGH}

Suggested Fix

Instead of calling process.exit(130) directly in the useInput handler, the component should signal the InkUI instance to initiate a graceful shutdown. This could be done by calling a dedicated cancel method, which would then throw a WizardCancelledError. This allows the await using block in wizard-runner.ts to correctly trigger the [Symbol.asyncDispose] method, ensuring all resources are cleaned up and the terminal state is restored properly before the process exits.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/lib/init/ui/ink-app.tsx#L165-L169

Potential issue: When a user presses Ctrl+C while a spinner is active (and no prompt is
shown), a `useInput` handler in `ink-app.tsx` directly calls `process.exit(130)`. This
immediate process termination bypasses the `await using` disposal logic for the `InkUI`
instance. As a result, critical cleanup tasks in `[Symbol.asyncDispose]` are skipped.
This leaves the user's terminal in raw mode (disabling character echo) and leaks a
`/dev/tty` stream handle, which can prevent the process from exiting cleanly.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[sentry]

Bug: In the FilesPanel, pressing the Escape key incorrectly scrolls the view to the bottom because it's grouped with the End key in an input handler.
_{Severity: MEDIUM}

Suggested Fix

Remove the key.escape check from the conditional statement in the useInput handler. The condition should only check for key.end to trigger the scroll-to-bottom behavior, leaving the Escape key to its default (or no) action in this context.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/lib/init/ui/ink-app.tsx#L825-L828

Potential issue: In the `FilesPanel` component, the `useInput` handler incorrectly
groups the `key.escape` and `key.end` keys. When the 'Files' tab is active and no prompt
is open, pressing the Escape key triggers a scroll-to-bottom action, because the
condition `if (key.end || key.escape)` is met. This is an unexpected user experience, as
the Escape key is typically used for cancellation or as a no-op, and the UI does not
indicate it will cause a scroll action in this context.

[MathurAditya724]

Confirmed — this is a valid bug. Every other key.escape handler in this file (lines 1054, 1118, 1187) uses it for cancellation (prompt.resolve(null)). Grouping it with key.end here makes Escape scroll to the bottom, which is unexpected.

Suggested change

	if (key.end || key.escape) {
	setPinnedToBottom(true);
	setOffset(0);
	}
	if (key.end) {

[sentry]

Bug: The SIGINT handler uses process.on instead of the documented process.once, which prevents the intended force-exit safety mechanism on a second Ctrl+C signal during a stuck teardown.
_{Severity: LOW}

Suggested Fix

To implement the documented safety feature, change process.on("SIGINT", handler) to process.once("SIGINT", handler). This ensures that if the teardown process hangs, a second Ctrl+C signal will trigger Node.js's default behavior and terminate the process immediately. Alternatively, if ignoring subsequent signals is the desired behavior, update the comment to reflect the actual implementation.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/lib/init/ui/ink-ui.ts#L854-L864

Potential issue: A safety mechanism to handle a stuck teardown process is not
implemented correctly. A comment in `installCancelHandler` states that
`process.once('SIGINT', ...)` is used to allow a second Ctrl+C signal to force-exit the
application if the teardown hangs. However, the code actually uses `process.on('SIGINT',
...)`. In conjunction with a guard clause in `requestCancel`, this causes any subsequent
Ctrl+C signals to be silently ignored. While the current synchronous `tearDown`
implementation makes a hang unlikely, this discrepancy means the intended protection
against a stuck process is missing.

[MathurAditya724]

Good catch. The comment says process.once but the code used process.on. With process.on, the handler stays registered and the cancelRequested guard in requestCancel() silently swallows subsequent SIGINTs — so a second Ctrl+C during a stuck teardown would be a no-op instead of falling through to Node's default handler (force exit).

Fixed in 90c76b4 — changed process.on("SIGINT", handler) to process.once("SIGINT", handler).

[sentry]

Bug: The SIGINT handler uses process.on instead of the documented process.once, preventing a second Ctrl+C from force-exiting a hung teardown process.
_{Severity: MEDIUM}

Suggested Fix

Replace process.on('SIGINT', handler) with process.once('SIGINT', handler). This aligns the code with the documentation and ensures that after the first cancellation signal, a subsequent SIGINT will trigger Node's default behavior, which is to terminate the process immediately.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/lib/init/ui/ink-ui.ts#L854-L865

Potential issue: The docstring for `installCancelHandler` states that `process.once` is
used for the `SIGINT` handler to allow a second Ctrl+C to force-exit the process.
However, the implementation at line 864 uses `process.on`. If the `tearDown()` process
hangs, the listener remains active. A subsequent Ctrl+C will trigger the handler, but an
early return due to the `cancelRequested` flag at line 729 prevents any action, trapping
the user in a hung state without the ability to force-exit.

[MathurAditya724]

Valid catch. The earlier fix (90c76b4) switched to process.once but that was reverted in 361da11 because once gets consumed by a prompt-delegation Ctrl+C (where requestCancel returns early without setting cancelRequested), leaving subsequent signals unhandled.

The real fix is to keep process.on for persistence but change the cancelRequested guard from a silent no-op to a force-exit. Fixed in 28e9e93 — a second Ctrl+C while teardown is in progress now calls process.exit(130) instead of returning. Updated docstrings in both requestCancel and installCancelHandler to reflect the actual behavior.

[sentry]

Bug: A race condition between tearDown() and a queued learnTimer callback can lead to startTipRotation() being called after teardown, leaving an uncleared tipTimer.
_{Severity: MEDIUM}

Suggested Fix

To prevent the race condition, add a check for the this.torndown flag inside the learnTimer callback before calling startTipRotation(). This ensures that if tearDown() has been initiated, no new timers will be created.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/lib/init/ui/ink-ui.ts#L822-L831

Potential issue: A race condition exists in the component's teardown logic. If
`tearDown()` is called at a specific moment after a `learnTimer` callback has been
queued but before it executes, the `clearInterval` call in `tearDown` will not prevent
that queued callback from running. When this callback runs, it can call
`startTipRotation()`, which sets a new `tipTimer`. Because the `tearDown` logic has
already completed, this new timer will never be cleared, resulting in a memory leak and
potentially unexpected behavior from the orphaned interval.

[MathurAditya724]

Good catch — this is a real race. A queued learnTimer callback can fire after tearDown() clears the interval, calling startTipRotation() and leaving an orphaned tipTimer.

Fixed in 54b64de by adding a this.torndown guard at the top of the callback.