fix: format embedded code in-process so the binary stops hanging on .vue

[gocanto]

The bug

The self-contained binary hangs forever (needs SIGKILL) on any file with embedded code — .vue (<template>/<style>), markdown, HTML. Plain .ts/.tsx are unaffected.

Reproduced with a 6-line SFC in a fresh git repo, so it is not project-specific:

$ fmtkit ts Min.vue
[blank-lines] processed 1 file(s), 0 changed
Expected at least one target file. All matched files may have been excluded by ignore rules.   (x5)
error: Worker exited unexpectedly
      at onUnexpectedExit (/$bunfs/root/fmtkit-ts-sidecar:2657:32)
<hangs>

Regression from #48 (Docker → single binary). The Docker image formatted these same files fine, so this is v0.5.x-only.

Root cause

.vue makes oxfmt use its external/embedded formatter, a Tinypool pool with runtime: "child_process" (oxfmt/dist/cli.js). That pool forks worker entry scripts:

• oxfmt/dist/cli-worker.js — referenced via new URL("./cli-worker.js", import.meta.url)
• tinypool/dist/entry/process.js — forked via fileURLToPath(import.meta.url + "/../entry/process.js")

Both are reached through runtime URL strings, so bun build --compile never traces or embeds them — they resolve to non-existent /$bunfs/root/… paths. Every forked worker dies on startup → Tinypool emits Worker exited unexpectedly → Tinypool.destroy() awaits an once(worker, 'exit') that never settles → the process wedges. (fork() also re-execs the compiled binary itself, which compounds it.)

The misleading Expected at least one target file… line is oxfmt's native diagnostic for thread-pool spawn failure, printed once per dead worker — not an ignore-rules problem.

Plain .ts never initialises the pool, and the smoke fixture had no embedded-code file, which is why this shipped.

The fix

The four pooled functions (formatFile, formatEmbeddedCode, formatEmbeddedDoc, sortTailwindClasses) are stateless prettier calls — the pool only bought cross-file parallelism, not isolation. So instead of wrestling worker entries into the bundle, this rewrites oxfmt's worker-proxy at release-staging time to call them directly on the main thread, deleting the unusable worker layer.

• infra/scripts/release/patch-oxfmt-inprocess.mjs (new) — discovers oxfmt's hashed API module + export aliases from cli-worker.js, asserts the exact worker-proxy structure, and swaps the Tinypool block for in-process calls. Exits non-zero on any drift, so an oxfmt bump can't silently reintroduce the hang.
• stage-ts-assets.sh — runs the patch after npm install, before bun --compile (once; all four targets share the patched workdir).
• test-binary-smoke.sh — adds a Vue SFC fixture exercising all three sections, closing the coverage gap that let this ship.

Same function names and Promise-returning shape as the originals, so the rest of cli.js (the runCli wiring, the disposeExternalFormatter call) is untouched.

Trade-off

Embedded-code formatting is now single-threaded within each oxfmt process. For typical repos this is a wash or faster — it also sheds the per-worker prettier startup cost — but a very large Vue/markdown codebase loses that parallelism. A proper worker_threads-based pool could restore it later if profiling calls for it; correctness first, since the current state is "hangs forever".

Verification

• fmtkit ts <sfc>.vue → exit 0 in ~2s, <script>/<template>/<style> all formatted (the <style> CSS reformatting proves the embedded path runs).
• edgekit's 21 real .vue files → no hang, exit 0.
• All four release targets (darwin_*, linux_*) cross-compile.
• go test ./... green; test-binary-smoke.sh green (now including the Vue fixture).

Sidecar grows ~2.2MB (70.6 → 72.8MB darwin_arm64): the prettier/embedded-language stack is now genuinely reachable and bundled — previously it was neither embedded nor loadable, which is the other half of why the worker path could never have worked.

[gemini-code-assist]

Code Review

This pull request introduces a patch script, patch-oxfmt-inprocess.mjs, to rewrite oxfmt's CLI so that it formats embedded code in-process rather than using a Tinypool worker pool, resolving process hangs in bun-compiled binaries. The patch is integrated into the release staging pipeline, and a Vue SFC smoke test is added to prevent regressions. Feedback on the changes suggests making the shim functions asynchronous to properly await underlying API calls before passing them to synchronous helpers, and making the import alias parsing more robust to handle cases where as aliases are not used.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The original pooled functions in worker-proxy.ts returned Promises because they were executed via Tinypool. If the underlying oxfmt API functions (like __fmtkitFormatFile) are asynchronous (e.g., if they call Prettier v3 APIs which are async), they will return Promises. Passing a Promise directly to synchronous helper functions like toFormatFileResult or toNullable will cause them to fail or behave incorrectly.

By making the shim functions async and using await on the inner API calls, we guarantee that:

1. The helper functions always receive the resolved value (whether the API is sync or async).
2. The shim functions always return a Promise, preserving the exact Promise-returning contract of the original pooled functions.

Suggested change

	function formatFile(options, code) {
	return toFormatFileResult(__fmtkitFormatFile({ options, code }));
	}
	function formatEmbeddedCode(options, code) {
	return toNullable(__fmtkitFormatEmbeddedCode({ options, code }));
	}
	function formatEmbeddedDoc(options, texts) {
	return toNullable(__fmtkitFormatEmbeddedDoc({ options, texts }));
	}
	function sortTailwindClasses(options, classes) {
	return toNullable(__fmtkitSortTailwindClasses({ options, classes }));
	}
	async function formatFile(options, code) {
	return toFormatFileResult(await __fmtkitFormatFile({ options, code }));
	}
	async function formatEmbeddedCode(options, code) {
	return toNullable(await __fmtkitFormatEmbeddedCode({ options, code }));
	}
	async function formatEmbeddedDoc(options, texts) {
	return toNullable(await __fmtkitFormatEmbeddedDoc({ options, texts }));
	}
	async function sortTailwindClasses(options, classes) {
	return toNullable(await __fmtkitSortTailwindClasses({ options, classes }));
	}

[gocanto]

Thanks — I checked this against the real helpers, and it's the opposite way round: toFormatFileResult and toNullable are not synchronous. They're Promise wrappers (oxfmt/dist/napi-callbacks-*.js):

async function toFormatFileResult(run) {
	return run.then((code) => ({ ok: true, code })).catch((err) => ({ ok: false, error: errorToMessage(err) }));
}
async function toNullable(run) {
	return run.catch(() => null);
}

They call run.then(...) / run.catch(...), so they need the Promise itself. Awaiting first hands them a resolved string, which has no .then. Running both variants against those exact helpers:

A (this PR: pass the Promise)   ok -> { ok: true, code: 'formatted:x' }
A                              err -> { ok: false, error: 'Error: boom' }
A                        toNullable -> null
B (suggested: await first)      ok -> THROWS: TypeError: run.then is not a function
B                              err -> THROWS (rejection escapes): boom

So the suggestion breaks it twice over: the immediate TypeError, and — even were that fixed — rejections would escape as exceptions instead of becoming { ok: false, ... } / null, which is the fallback behaviour the Rust caller relies on.

The premise is right that the API functions are async; that's exactly why passing the Promise through is correct. pool.run(...) returned a Promise before, and an async API call returns a Promise now — the contract is preserved by construction, without needing async on the shim.

Covered end-to-end by the Vue fixture in test-binary-smoke.sh: the <style>/<template> blocks only format if this path works. Leaving as-is, with the reasoning documented on ShimSource.workerProxyRegion() so the next reader doesn't have to re-derive it.