MareStare (Jun 05 2025 at 02:41): MareStare (Jun 05 2025 at 02:41):Hi, my goal is to expose a small parser library with several functions from Rust to JS to be able to use it in a VSCode extension. My Rust code has zero dependencies and it does no IO. I tried building it with wit-bindgen and cargo build --target wasm32-wasip2, and then transpiling the resulting .wasm with jco, but the problem is that the output seems to depend on wasi imports. I want my VSCode extension to be compatible with the web (browser) environment. Is there a way to disable wasi APIs for my component? Or maybe I shouldn't just use the component model and use wasm-bindgen in this case?
Ramon Klass (Jun 05 2025 at 03:19):if you want something that can run in browsers reliably I would not use wasip2 currently, since your library really does not need libc, wasm-bindgen would be much more straightforward and doesn't require any host imports unless you want to use some
Milan (rajsite) (Jun 05 2025 at 03:36):Wasi-virt should let you plug any imports you know you don't need: https://github.com/bytecodealliance/WASI-Virt
Milan (rajsite) (Jun 05 2025 at 03:39):If you end up exposing an API surface area via WIT then jco transpile can help take a wasi p2 based component and generate browser compatible js + wasm: https://bytecodealliance.github.io/jco/transpiling.html
MareStare (Jun 05 2025 at 10:51):Thank you for sharing your knowledge :folded_hands:. I guess wasm-bindgen will be the simplest approach in this case, but wasm-virt also looks cool, I'll keep that in mind.
I thought there could be a way to specify which wasi apis the Rust library should compile with when I build it with cargo. Something like wasm-virt but right during build instead of in a post-processing. I guess cargo will always output a binary that depends on all wasi APIs
Victor Adossi (Jun 05 2025 at 11:09):Hey @MareStare what you can also do is build for wasm32-unknown-unknown as the target with a tool like cargo component!
If you want to do the build with just cargo, you need to pull down nightly. This comes up from time to time:
That gets you the Rust Webassembly binary without the deps imported, and from there, transpiling with jco should not introduce those deps!
MareStare (Jun 05 2025 at 11:43):Interesting, I did try to build for wasm32-unknown-unknown, but it looked like the resulting .wasm wasn't using the component model even though I used wit-bindgen in it. I guess cargo-component would have fixed that. Thanks for the suggestion :+1:
Victor Adossi (Jun 05 2025 at 12:21):Ah yes, so unfortunately this bit is counter intuitive -- wasm32-unknown-unknown doesn't use the component model (or WASI) -- it's more from the world before WASI.
The thing is, cargo-component is component-only, so it interprets that to to mean "no wasi, but still produce a component", which is a bit of a nonsensical command, but it's the way that we have to do it w/ cargo component
Victor Adossi (Jun 05 2025 at 12:22):Then of course, in Rust land (which maybe makes the most sense), no extra WASI deps are added for a normal app, but the panic machinery being available by default pulls in the dependencies, so to get them out you have to strip out the panic machinery (which requires nightly)
MareStare (Jun 05 2025 at 13:08):Interesting, now you made me wonder how panics and std io work in wasm32-unknown-unknown without wasi at all :thinking:. I guess I'll have to experiment
Last updated: Dec 06 2025 at 05:03 UTC