Support plugins in `@swc/wasm-*`

[kwonoj]

Describe the feature

The stories around supporting plugins in SWC (#3540) did not cover wasm host version of the SWC, namely @swc/wasm and @swc/wasm-web. Currently, wasm host version of SWC lacks of any kind of plugin support including existing JS based one. This issue tracks to support plugins universally across any runtime we support, including wasm host version.

The scope of plugin support is limited to the new, experimental plugin written in wasm. I do not have conclusions if it's technically possible to support JS written plugin or not but in either case we do not aim to support it in here.

Plugin support in wasm host have working proof of concept at https://github.com/kwonoj/swc/tree/feat-plugin-js-wasm-host nowhere close to ready to be included in core. There are lots of problems need to be solved separately, however it proves main concept of let internal webassembly runtime we use can borrow host runtime's webassembly compiler if it runs on the supported platform. Notably, this means web brower & node.js.

These are known subtasks to achieve initial working experimental support.

• wasm-unknonw-unknown plugin panic with unknown import #3591 : to support wasm32-unknown-unknown plugin.
• Fix memory access issue in PluginTransformTracker : Somehow accessing guest memory ref fails only with PluginTransformTracker's init logic, works fine with raw poc code. : Wasmer/js raises cannot read property 'buffer' when try to access memory via Env wasmerio/wasmer#2816
• Solve compilation config to support wasmer and wasmer/js selectively
• Non-prod ready but support loading wasm binary dynamically
• Wasm32-wasi plugin support story: likely this is upstream (browser / node) runtime issue.

Babel plugin or link to the feature description

#3540

Additional context

No response

[kwonoj]

Upstream issues:

• ChainResolver and memory uninitialized wasmerio/wasmer#2752
• Would you able to publish a new version? servo/string-cache#257
• Wasmer/js raises cannot read property 'buffer' when try to access memory via Env wasmerio/wasmer#2816

[magic-akari]

• Wasm32-wasi plugin support story: likely this is upstream (browser / node) runtime issue.

Does this "story" refer to https://github.com/WebAssembly/component-model ?

[kwonoj]

Does this "story" refer to WebAssembly/component-model ?

No. It's about executing wasm plugin itself - when the runtime (wasmer) runs in wasm-host, it does not embed own runtime but tries to borrow host's runtime to execute wasm binary instead. So unlike native swc binary, it'll run via node.js / browser's wasm runtime. Currently we recommend to build plugin with wasi, and expose some system access (like filesystem) so to run those correctly host runtime need full support for wasi.

[kdy1]

@kwonoj Is there any update?

[jantimon]

I understand this issue might be quite tricky to solve but could you please take a new look in 2025?

Right now SWC plugins do not work in stackblitz - that complicates reproduction examples a lot.

Also we would love to show an interactive playground for our SWC plugin but that's also not possible with WASM.