Runtime portability improvements

[sliemeobn]

as discussed in #477

This PR

• makes sure the Runtime remains compatible with "isolatedModules" (ie: esbuild, rollup, ...)
• move the JSBridge stubs out of the plugin template for better reusability

I think these changes are good even when the whole "how to best bundle/deploy/build/package" is not fully clear yet.

[sliemeobn]

unfortunately this tsconfig setting "isolatedModules": true messes up the codegen for export const enum Kind
I reverted it for now, but maybe we should add CI checks for the Runtime "buildability" somehow?

[kateinoigakukun]

I still do not want to expose the Runtime code as an API because maintaining a stable interface at that layer requires much effort.

[sliemeobn]

@kateinoigakukun I understand the concern. I don't think this PR changes anything in that regard.

[kateinoigakukun]

Sorry, I still can't see a clear benefit in merging this change.

I've gone through the discussion and the measurements again, and I still can't support this direction. The latency we are seeing comes from the implementation details of SwiftPM's plugin evaluator with native build system (especially the manifest caching disablement is the major 100ms-level bottleneck), not from the SwiftPM's plugin architecture itself. Once SwiftPM's swift-build migration lands, that overhead disappears, so we don't have a strong reason to work around plugins on our side.

Also the BridgeJS stubs are just a hack, and they won't be necessary after we start using BridgeJS inside JavaScriptKit, so I don't want to split it out now.

[MaxDesiatov]

Once SwiftPM's swift-build migration lands, that overhead disappears, so we don't have a strong reason to work around plugins on our side.

Have either of you tested how this works with --build-system swiftbuild that's already available in main and 6.3 toolchain snapshots? We need to make sure that any bugs in that flow are found early, reported back, and ideally fixed before it eventually becomes the default.

[kateinoigakukun]

@MaxDesiatov It's not working today swiftlang/swift-package-manager#9364

[sliemeobn]

I think we should continue this discussion in issue #477.

Let me reiterate that I fully understand the concerns and the wish to have a maintainable solution that takes the future build system and bridge-js features into account. However, in my view this PR is independent of those topics - it neither pushes us in any specific direction nor prevents us from going in any direction later.

It simply:

• fixes a missing import
• improves the typing of an export
• makes shim implementations accessible that are (and will for this version forever be) required as wasm imports

[kateinoigakukun]

Thanks for summarizing it 🙏 I support the first two points, but still not very sure about the third one. I don't think the third one is independent from #477 direction, so I'm a bit confused.

At least, exposing every bjs intrinsic import function names as type declaration increases the number of files we need to edit to add intrinsic, and also I personally don't want to consider the import function list being a public API.

How about exposing createInstantiator instead? It allows us to keep the BridgeJS stubs as implementation details while giving you the flexibility to satisfy imports with custom bootstrap code outside of PackageJS.