xxxigm 18297899d7 fix(tui): drop ink-text-input re-export from @hermes/ink entry-exports (#31227) ... 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.		2026-07-01 02:10:32 -07:00
..
hermes-ink	fix(tui): drop ink-text-input re-export from @hermes/ink entry-exports (#31227)	2026-07-01 02:10:32 -07:00