mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-07-13 14:02:16 +00:00
18297899d7
The dashboard TUI bundle hung at startup with only 141 bytes of ANSI reset sequences and a blank screen forever. Root cause: esbuild's lightweight `__esm` helper at the top of `dist/entry.js` does not await nested async init, so a circular async cycle in the module graph never resolves. The cycle came from re-exporting ``TextInput`/`UncontrolledTextInput`` from `'ink-text-input'` here — that npm package depends on the upstream `ink` package, whose graph loops back through React + our in-tree `@hermes/ink` ink fork. The result: `init_entry_exports` was emitted as `async … await init_build4()` (where `build4` is `node_modules/ink-text-input/build`), and the top-level `await Promise.all([init_entry_exports().then(...)])` in `src/entry.tsx` deadlocked waiting on the dangling Promise. Nobody in `ui-tui/` actually imports `TextInput` from `@hermes/ink` — the composer uses the in-tree `src/components/textInput.tsx` widget instead. Drop the re-export from the source so the bundle no longer inlines the upstream ink graph at all. Callers that legitimately want the upstream widget can still import it from the dedicated `@hermes/ink/text-input` subpath, which sits outside `entry-exports` and so does not get inlined into consumers' bundles. After the fix: * `dist/entry.js` shrinks from 2.9MB → 2.4MB (~11.5k fewer bundled lines) with zero `async __esm` wrappers remaining. * `init_entry_exports` is now a synchronous `__esm` module. * The bundle's top-level await chain resolves in ~30ms instead of hanging. |
||
|---|---|---|
| .. | ||
| src | ||
| ambient.d.ts | ||
| index.d.ts | ||
| index.js | ||
| package.json | ||
| text-input.d.ts | ||
| text-input.js | ||