From 53d2c4191f5228d107593ea2db3addadbc01954c Mon Sep 17 00:00:00 2001 From: xxxigm Date: Sun, 24 May 2026 08:45:30 +0700 Subject: [PATCH] docs(tui): clarify why @hermes/ink is aliased to source in build.mjs Update the comment on the `alias` entry to mention the second reason the source-inline is needed: keeping the upstream `ink` / `ink-text-input` graph out of the bundle (which fixed the startup deadlock in #31227). Code path is unchanged. --- ui-tui/scripts/build.mjs | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/ui-tui/scripts/build.mjs b/ui-tui/scripts/build.mjs index 2c7b55f76..f9494ca43 100644 --- a/ui-tui/scripts/build.mjs +++ b/ui-tui/scripts/build.mjs @@ -35,9 +35,14 @@ await build({ outfile: out, jsx: 'automatic', jsxImportSource: 'react', - // Skip the prebuilt @hermes/ink bundle — esbuild's __esm helper doesn't - // await nested async init, which breaks lazy-initialized exports like - // `render`. Bundling from source sidesteps that. + // Skip the prebuilt @hermes/ink bundle and inline the source instead: + // (1) esbuild's `__esm` helper does not await nested async init, so the + // prebuilt bundle's lazy `render` would never resolve when nested in + // this top-level Promise.all; (2) bundling from source also lets us + // keep `ink-text-input` and the upstream `ink` graph OUT of the + // bundle entirely — re-exporting them from entry-exports created a + // circular async chain that hung the TUI at startup with only ANSI + // reset bytes on screen (#31227). alias: { '@hermes/ink': resolve(root, 'packages/hermes-ink/src/entry-exports.ts') }, plugins: [stubDevtools], // Some transitive deps use CommonJS `require(...)` at runtime. ESM bundles