build: bundled OpenTUI chunk is empty, `step` fails with `createLocalTuiClientApp` not exported

[li-xiu-qi]

Bug description

After running the installer (bash scripts/setup.sh), the step command fails immediately with:

step-cli error: OpenTUI runtime did not export createLocalTuiClientApp()

Environment

• step-realtime-cli version: 1.0.0
• Node version: v22.14.0
• OS: Linux (Ubuntu / WSL)
• Package manager: pnpm 10.17.0

Reproduction steps

1. git clone https://github.com/stepfun-ai/Step-Realtime-CLI.git
2. cd Step-Realtime-CLI
3. bash scripts/setup.sh
4. Open a new shell (so ~/.step-cli/bin is on PATH)
5. step

Expected behavior

The interactive TUI starts.

Actual behavior

The process exits immediately with:

step-cli error: OpenTUI runtime did not export createLocalTuiClientApp()

Root cause analysis

The bundle produced by tsdown / rolldown 1.0.0-beta.7 splits src/runtime/local-tui-app.ts into a dynamic chunk (dist/local-tui-app-<hash>.js). However, that chunk is effectively empty (only 3 lines of imports) and does not contain the createLocalTuiClientApp export or the LocalStepCliTuiApp class.

grep shows the symbol is referenced in dist/index.js but never defined in any built chunk:

$ grep -rl 'createLocalTuiClientApp' dist/
dist/index.js
dist/index.cjs

$ cat dist/local-tui-app-dRVjt31N.js
import "./local-session-target-DAN8-Cwd.js";
import "./local-tui-bootstrap-xGRRjkP0.js";
import process from "node:process";

The LocalStepCliTuiApp class is missing from the chunk entirely, so the runtime guard

if (typeof runtimeModule.createLocalTuiClientApp !== 'function') {
  throw new Error('OpenTUI runtime did not export createLocalTuiClientApp()');
}

fails at runtime.

Workaround

Running the entrypoint directly via tsx bypasses the bundled artifacts and starts the TUI correctly:

rm -rf dist
node bin/step-cli.js
# → falls back to: running src/index.ts via tsx

Impact

This breaks the default installation path for any user whose launcher resolves to the bundled dist/index.js.

Related files

• src/runtime/local-tui-app.ts
• src/runtime/open-tui-capability.ts
• tsdown.config.ts

[li-xiu-qi]

Submitted a fix in #28.

Changes:

• tsdown.config.ts: add runtime/local-tui-app as an explicit entry so the dynamic import resolves to a chunk that actually exports createLocalTuiClientApp.
• scripts/build-packages.mjs: add @step-cli/agent-sdk to the build targets because extensions/realtime-voice imports it and its dist/ was never produced.

With these changes pnpm build emits a non-empty dist/runtime/local-tui-app.js and packages/agent-sdk/dist/index.js, and node bin/step-cli.js --version works against the built artifacts.

[li-xiu-qi]

After the build fix in #28, the TUI entry now resolves successfully, but launching the TUI surfaces two separate upstream OpenTUI runtime issues on standard Node.js. Tracked in #29:

• react-reconciler/constants import missing .js extension in @opentui/react
• bun-webgpu (a transitive dep of @opentui/core) using Bun-only bun: protocol imports

These prevent the TUI from starting on stock Node.js even after createLocalTuiClientApp is correctly emitted.

[Lion-1209]

Adding Windows native Node (not WSL) reproduction data. I confirm both #25 and #29, and hit one earlier wall that #29 doesn't mention.

Environment: setup.ps1 (per README), Windows 11, Node v24.13.0, no Bun installed, step-realtime-cli 1.0.0 (commit 0100233), @opentui/core/@opentui/react@0.1.90.

#25 repro: After a clean uninstall + reinstall, step in a fresh PowerShell window fails immediately with OpenTUI runtime did not export createLocalTuiClientApp(); step --version works. Root cause matches #25 — dist/local-tui-app-<hash>.js is an empty shell (3 import lines), createLocalTuiClientApp has no definition anywhere in dist/; importing the chunk directly returns exports: [].

On #29: Even after #28 fixes the empty chunk, Windows native Node still can't reach the TUI. I exercised each layer of the OpenTUI render stack on this machine and confirmed it is Bun-only — and there's an earlier wall #29 doesn't list:

1. .scm imported as a module (earliest; Node fails here) — @opentui/core loads tree-sitter highlight queries via an import attribute:
   import javascript_highlights from "./assets/javascript/highlights.scm" with { type: "file" } (index.js:8432)
   Node throws Unknown file extension ".scm". This fires before bun:ffi, so Windows native Node never even reaches runtime: OpenTUI dependencies fail on standard Node.js after build fix #29's errors.
2. react-reconciler/constants without extension (= runtime: OpenTUI dependencies fail on standard Node.js after build fix #29 Error 1) — react-reconciler@0.32.0 has no exports map; Node's ESM loader can't resolve the bare subpath. Verified: react-reconciler/constants fails, react-reconciler/constants.js resolves.
3. bun-webgpu → bun:ffi protocol (= runtime: OpenTUI dependencies fail on standard Node.js after build fix #29 Error 2) — @opentui/core pulls in bun-webgpu@0.1.5 via optionalDependencies; its source imports heavily from bun:ffi, and Node throws Received protocol 'bun:'.

These three (plus the native opentui.dll load from #29) share one root cause: OpenTUI assumes a Bun runtime — Bun's lenient loader understands the bun: scheme, .scm files, and import attributes, while Node's ESM loader does not. Net effect: TUI mode currently runs only under Bun, yet the README's Windows path (setup.ps1, Node launcher) contradicts that.

One smoke-test gap worth flagging: the installer only runs step --version (setup.ps1:242), but this error only fires on the interactive TUI path (stdin/stdout.isTTY === true), so the install always reports "success." A forced-TTY interactive-launch smoke (or a real step launch in CI) would catch #25-class issues.

---

补充一份 Windows 原生 Node(非 WSL) 的实测证据。确认 #25 / #29 的同时,还遇到一个 #29 未记录、更早出现的拦路点,一并报上来。

环境:setup.ps1(README 标准),Windows 11,Node v24.13.0,未安装 Bun,step-realtime-cli 1.0.0(commit 0100233),@opentui/core/@opentui/react@0.1.90。

#25 复现:全新卸载 + 重装后,在新 PowerShell 窗口运行 step,立即报 OpenTUI runtime did not export createLocalTuiClientApp();step --version 正常。根因与 #25 一致——dist/local-tui-app-<hash>.js 是空壳(仅 3 行 import),createLocalTuiClientApp 在整个 dist/ 无定义,直接 await import() 该 chunk 返回 exports: []。

关于 #29:即便 #28 修好空 chunk,Windows 原生 Node 仍进不了 TUI。我在本机逐层实测了 OpenTUI 渲染栈,确认它是 Bun-only 的——而且有一处 #29 没记到的更早的墙:

1. .scm 被 import(最早,Node 在此即挂) —— @opentui/core 用 import attribute 加载 tree-sitter 高亮查询:
   import javascript_highlights from "./assets/javascript/highlights.scm" with { type: "file" }(index.js:8432)
   Node 报 Unknown file extension ".scm"。这一步在 bun:ffi 之前就触发,所以 Windows 原生 Node 连 runtime: OpenTUI dependencies fail on standard Node.js after build fix #29 的错误都看不到。
2. react-reconciler/constants 无扩展名(=runtime: OpenTUI dependencies fail on standard Node.js after build fix #29 Error 1)—— react-reconciler@0.32.0 无 exports map,Node ESM 无法解析裸子路径;实测 react-reconciler/constants fail、react-reconciler/constants.js OK。
3. bun-webgpu → bun:ffi 协议(=runtime: OpenTUI dependencies fail on standard Node.js after build fix #29 Error 2)—— @opentui/core 经 optionalDependencies 拉入 bun-webgpu@0.1.5,其源码大量 import { ... } from "bun:ffi",Node 报 Received protocol 'bun:'。

这三处(以及 #29 记录的原生 opentui.dll 加载)本质同源:OpenTUI 假设运行时是 Bun——Bun 宽松的 loader 认识 bun: 协议、.scm 扩展名和 import attribute,而标准 Node 的 ESM loader 都不认。结论是 TUI 模式目前只能在 Bun 下运行,而 README 的 Windows 安装路径(setup.ps1,Node 启动器)与此矛盾。

另外提一个冒烟测试盲区:安装脚本末尾只跑 step --version(setup.ps1:242),而本错误只在交互式 TUI 路径触发(需 stdin/stdout.isTTY === true),所以安装永远显示"成功"。建议增加一条强制 TTY 的交互式启动冒烟,或在 CI 跑一次真 step 启动,可堵住 #25 这类问题。

[ZouR-Ma]

Thanks for opening this!

We've set up a contribution workflow. If anything is missing (repro steps, version, environment, logs), please refile using one of our templates:

https://github.com/stepfun-ai/Step-Realtime-CLI/issues/new/choose

For logs, run with LOG_LEVEL=debug.

If you'd like to fix it yourself, open a PR referencing this issue with Closes #<number>.

See:
https://github.com/stepfun-ai/Step-Realtime-CLI/blob/main/CONTRIBUTING.md