fix(workflows): bundle via esbuild CLI, not the Node service or a global env - #70
Merged
Conversation
…bal env
The ESBUILD_BINARY_PATH fix stopped the ENOENT but the packaged app then hit
"The service is no longer running: write EPIPE" — esbuild's async build()
keeps a long-lived service child spawned with stdio[2]:'inherit', which in a
packaged Windows Electron GUI app (no valid parent stderr) dies right after
launch, so every workflow lists as broken. buildSync avoids the service but
spins a worker thread that is fragile in a host already running esbuild (it
crashes vitest's own esbuild).
Bundle by spawning the esbuild binary one-shot via execFileSync with piped
(not inherited) stdio: no persistent service, no worker thread, no inherited
stderr — identical in dev and packaged, and esbuild's real stderr surfaces in
{error} instead of the opaque EPIPE.
Also drop the process.env.ESBUILD_BINARY_PATH mutation from the previous
commit: a global env leaks into every child the app spawns (agents/CLIs),
forcing their own differently-versioned esbuild onto this 0.25.12 binary and
breaking them with a host/binary version mismatch (observed: it broke a
spawned Claude Code session's vitest, whose esbuild is 0.27.7). Resolve the
binary once in main (packaged → app.asar.unpacked; dev → node_modules) and
pass it explicitly into the loader.
Verified: full suite 488→489 green (new invalid-binary regression test);
build:win, then a one-shot execFileSync of the unpacked binary bundles the
real revisar-pr workflow.ts (238 bytes) — the exact packaged code path.
Closes #68
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Owner
Author
|
✅ Validado em runtime no app empacotado. Rodei o |
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
1 participant
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.
Segue o PR #69 (que corrigiu só o
ENOENT). No app empacotado, com o caminho do binário já correto, apareceu:Causa (dois bugs empilhados)
loadWorkflowusava a API assíncronaesbuild.build(), que mantém uma service persistente spawnada comstdio[2]: 'inherit'. Num app Electron GUI empacotado no Windows (sem stderr válido no pai) essa service morre logo após subir → a próxima escrita no stdin dáwrite EPIPE→ todo workflow fica broken. (buildSyncevita a service, mas spawna um worker thread frágil — quebra até a service esbuild do vitest.)process.env.ESBUILD_BINARY_PATHglobal. Isso vaza para todo processo filho que o app spawna (agents/CLIs), forçando o esbuild deles (outra versão) sobre este binário 0.25.12 →Host version X does not match binary version 0.25.12. Observado ao vivo: quebrou o vitest de uma sessão Claude Code spawnada pelo app (esbuild 0.27.7).Correção
execFileSynccom stdio piped (não inherited): sem service persistente, sem worker thread, sem stderr herdado. Idêntico em dev e empacotado; o stderr real do esbuild aparece em{error}no lugar do EPIPE opaco.app.asar.unpacked; dev →node_modules) e passado explicitamente ao loader. SemESBUILD_BINARY_PATHglobal → sem vazamento.Verificação
npm test→ 489 verdes (novo teste de regressão: binário inválido ⇒{error}).typecheck+lintlimpos.build:win, depois umexecFileSyncone-shot do binário unpacked bundleando orevisar-prreal (238 bytes) — o caminho exato do código empacotado.Closes #68
🤖 Generated with Claude Code