Skip to content

fix: use export type for SwiftRuntimeThreadChannel re-export#742

Open
shivanshu877 wants to merge 1 commit into
swiftwasm:mainfrom
shivanshu877:fix/export-type-swiftruntimethreadchannel
Open

fix: use export type for SwiftRuntimeThreadChannel re-export#742
shivanshu877 wants to merge 1 commit into
swiftwasm:mainfrom
shivanshu877:fix/export-type-swiftruntimethreadchannel

Conversation

@shivanshu877
Copy link
Copy Markdown

Fixes #477

SwiftRuntimeThreadChannel is a TypeScript type alias, not a value. Re-exporting it with the value-style export { ... } causes esbuild and rolldown (which run in isolatedModules mode by default) to fail with:

Cannot re-export a type when 'isolatedModules' is enabled.

This breaks anyone trying to bundle JavaScriptKit with Vite or other esbuild/rolldown-based toolchains.

Changing to export type { SwiftRuntimeThreadChannel } makes the intent explicit and restores compatibility with esbuild/rolldown without affecting tsc or any runtime behaviour — a value-only consumer wouldn't be importing this anyway.

Test plan

  • tsc still compiles cleanly.
  • Type-only consumers still resolve the import.
  • Local verification with esbuild / rolldown is welcome from a maintainer with the toolchain set up.

SwiftRuntimeThreadChannel is a type alias, not a value. Re-exporting
it with `export { ... }` causes esbuild and rolldown (which run in
isolatedModules mode) to fail with "cannot re-export a type using
'export { ... }'" because the bundler cannot tell the export is
type-only at the module boundary.

Changing to `export type { SwiftRuntimeThreadChannel }` makes the
intent explicit and restores compatibility with esbuild/rolldown-based
build tools (Vite, etc.) without affecting tsc or any runtime
behaviour.

Reported in swiftwasm#477
@shivanshu877
Copy link
Copy Markdown
Author

Local verification (per @krodak's earlier request):

Ran on macOS 26 / Apple Swift 6.3.2:

  • cd Runtime && npm install && npm run build (Rollup) — succeeds with the export type { SwiftRuntimeThreadChannel } change. The whole point of the fix is making isolatedModules-mode bundlers (esbuild, rolldown) happy; the build going through rollup cleanly is the closest local equivalent.
  • swift test --package-path Plugins/BridgeJSall 134 tests in 10 suites pass (BridgeJSCodegenTests, BridgeJSLinkTests, JSClassMacroTests, etc.). No regressions from the re-export change.

(JavaScriptKit's full test suite needs the SwiftWasm toolchain + carton to execute the WebAssembly-side tests; those require the project's CI runners. The Mac-native subset above is what's directly affected by this PR.)

@krodak
Copy link
Copy Markdown
Member

krodak commented May 22, 2026

@shivanshu877

(JavaScriptKit's full test suite needs the SwiftWasm toolchain + carton to execute the WebAssembly-side tests; those require the project's CI runners. The Mac-native subset above is what's directly affected by this PR.)

Carton is not required, you can test locally with SwiftWasm toolchain, you will find instructions in .md files in repo. you might find those skills useful as well: https://github.com/swiftwasm/Swift-Wasm-Agent-Skill

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

JavaScript runtime portability

2 participants