fix(tui): resolve esbuild binary path in build.mjs to avoid version m…#27263
Open
jimmyjonezz wants to merge 1 commit into
Open
fix(tui): resolve esbuild binary path in build.mjs to avoid version m…#27263jimmyjonezz wants to merge 1 commit into
jimmyjonezz wants to merge 1 commit into
Conversation
…ismatch on Android arm64
On Android arm64 (Termux), the @esbuild/android-arm64 binary installed in
node_modules can end up with a different version than the esbuild package's
lib/main.js expects. For example, npm may install esbuild@0.27.7 as the JS
package while pulling @esbuild/android-arm64@0.28.0 as a dependency of a
transitive package (tsx). When esbuild's lib/main.js tries to start a service
subprocess, it reads the binary version from the spawned process's first
packet and compares it against the hardcoded host version, throwing:
Cannot start service: Host version "0.27.7" does not match binary version "0.28.0"
Root cause: ESBUILD_BINARY_PATH is read from environment and overrides the
local binary. On this system, ~/.hermes/esbuild-built exists (0.28.0) from a
previous installation and pollutes the build. Additionally,
require.resolve('@esbuild/android-arm64') in generateBinPath() can find the
wrong copy when multiple versions exist in the dependency tree (e.g.
node_modules/tsx/node_modules/@esbuild/android-arm64).
Previously attempted fixes (commits b3bd03703 and 5118502c7) tried using the
system esbuild at /usr/lib/node_modules/esbuild but that path contains version
0.28.0 which is also incompatible with the 0.27.7 lib/main.js in the project's
node_modules.
Fix:
- Clear ESBUILD_BINARY_PATH env var before loading esbuild (delete process.env.ESBUILD_BINARY_PATH)
- Import esbuild via createRequire from node:module to use the same require.resolve semantics as generateBinPath()
- The local esbuild package (esbuild + @esbuild/android-arm64 at matching versions) is already installed at ui-tui/node_modules/esbuild — this ensures the build script uses that pair consistently
Changes:
- build.mjs: create CJS require via createRequire, delete process.env.ESBUILD_BINARY_PATH, call esbuild.build() instead of bare build() import
This comment was marked as spam.
This comment was marked as spam.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolve esbuild binary path in build.mjs to avoid version mismatch on Android arm64
On Android arm64 (Termux), the @esbuild/android-arm64 binary installed in node_modules can end up with a different version than the esbuild package's lib/main.js expects. For example, npm may install esbuild@0.27.7 as the JS package while pulling @esbuild/android-arm64@0.28.0 as a dependency of a transitive package (tsx). When esbuild's lib/main.js tries to start a service subprocess, it reads the binary version from the spawned process's first packet and compares it against the hardcoded host version, throwing:
Cannot start service: Host version "0.27.7" does not match binary version "0.28.0"
Root cause: ESBUILD_BINARY_PATH is read from environment and overrides the local binary. On this system, ~/.hermes/esbuild-built exists (0.28.0) from a previous installation and pollutes the build. Additionally, require.resolve('@esbuild/android-arm64') in generateBinPath() can find the wrong copy when multiple versions exist in the dependency tree (e.g. node_modules/tsx/node_modules/@esbuild/android-arm64).
Previously attempted fixes (commits b3bd03703 and 5118502c7) tried using the system esbuild at /usr/lib/node_modules/esbuild but that path contains version 0.28.0 which is also incompatible with the 0.27.7 lib/main.js in the project's node_modules.
Fix:
Changes: