Running scriptc 0.0.36 under Bun 1.4.0 on macOS arm64 fails while starting the TypeScript 7 frontend, before compiling even a minimal input. This also affects installations where the node executable resolves to Bun.
I realize the README currently requires Node.js 24+. This report requests Bun host-runtime support and identifies the current blocker; it is not a report about Bun APIs in compiled programs.
Reproduction
With scriptc 0.0.36 already installed and its CLI executed by Bun (for example, when node resolves to Bun), create hello.ts containing:
Run:
scriptc build hello.ts --emit=ir
Actual result: exit code 1, with this error (installation prefixes omitted):
TypeError: undefined is not an object (evaluating 'stdout._handle.fd')
at new SyncRpcChannel (typescript/dist/api/syncChannel.js:131:34)
at new Client (typescript/dist/api/sync/client.js:36:25)
at new API (typescript/dist/api/sync/api.js:40:23)
at new Ts7Host (@scriptc/compiler/dist/frontend/ts7/program-adapter.js:81:20)
Expected for Bun support: emit IR successfully. At minimum, an unsupported host should produce an actionable diagnostic instead of an internal dependency stack trace.
Investigation
Ts7Host constructs the synchronous API from typescript/unstable/sync. In TypeScript 7.0.2, SyncRpcChannel obtains POSIX descriptors through the private Node stream properties stdout._handle.fd and stdin._handle.fd. Bun's child-process streams do not provide the required handle in this reproduction. Consequently, changing the native compiler or linker cannot fix this failure: --emit=ir fails too.
The current scriptc frontend uses the TS7 adapter throughout; the existing typescript5 dependency is not a drop-in frontend fallback. Actual Bun support needs a compatible synchronous transport in the dependency or an integration that preserves TS7's synchronous API and filesystem callbacks.
I checked existing issues and PRs for Bun, SyncRpcChannel, and _handle and found no matching report.
Running scriptc 0.0.36 under Bun 1.4.0 on macOS arm64 fails while starting the TypeScript 7 frontend, before compiling even a minimal input. This also affects installations where the
nodeexecutable resolves to Bun.I realize the README currently requires Node.js 24+. This report requests Bun host-runtime support and identifies the current blocker; it is not a report about Bun APIs in compiled programs.
Reproduction
With scriptc 0.0.36 already installed and its CLI executed by Bun (for example, when
noderesolves to Bun), createhello.tscontaining:Run:
Actual result: exit code 1, with this error (installation prefixes omitted):
Expected for Bun support: emit IR successfully. At minimum, an unsupported host should produce an actionable diagnostic instead of an internal dependency stack trace.
Investigation
Ts7Hostconstructs the synchronous API fromtypescript/unstable/sync. In TypeScript 7.0.2,SyncRpcChannelobtains POSIX descriptors through the private Node stream propertiesstdout._handle.fdandstdin._handle.fd. Bun's child-process streams do not provide the required handle in this reproduction. Consequently, changing the native compiler or linker cannot fix this failure:--emit=irfails too.The current scriptc frontend uses the TS7 adapter throughout; the existing
typescript5dependency is not a drop-in frontend fallback. Actual Bun support needs a compatible synchronous transport in the dependency or an integration that preserves TS7's synchronous API and filesystem callbacks.I checked existing issues and PRs for Bun, SyncRpcChannel, and
_handleand found no matching report.