Morning! I've been experimenting with various Wasm setups, just to see where we are at. I've noticed...

# webassembly

[Edoardo Luppi]

Morning! I've been experimenting with various Wasm setups, just to see where we are at.
I've noticed that wasmJs allows generateTypeScriptDefinitions(), but wasmWasi does not. Is it planned to add generateTypeScriptDefinitions() to wasmWasi?

[Artem Kobzar]

Could you please describe your use-case? We think that the TS definitions are only useful for the interop with JS/TS, but if there is some cases for WASI we can also discuss it.
Just for describing the imports and exports I feel that WIT-files would be much useful for the WASI target.

[Edoardo Luppi]

I get what you mean and I think it's reasonable.

My question spawns from the fact JsExport works for WASI too, and if you look at the outputted mjs file, the exports are indeed there, so the missing TS types felt like a misalignment with js and wasmJs

[Edoardo Luppi]

For a real use case I think I'll have to wait the moment I start using WASI with the Component Model

[Svyatoslav Kuzmich [JB]]

There is a tool https://github.com/bytecodealliance/jco for converting components into JS libs, and it includes the TS definition. I think this tooling fits better for integration into a JS/TS side of build system.

[Edoardo Luppi]

So basically what we'd be looking at is https://bytecodealliance.github.io/jco/transpiling.html
Correct? It would generate a JS integration layer that exposes the exported WebAssembly functions

[Edoardo Luppi]

Isn't that what you already do with the .mjs file tho? Or, kind of

[Svyatoslav Kuzmich [JB]]

Yes, but in a standard way. It is a Component Model spec polyfill/tranpiler, it is useful until it is implemented natively by JS engines (and maybe TS).

[Svyatoslav Kuzmich [JB]]

WASI target is designed to be completely JS agnostic. We currently run it in Node.js, but we will add standalone runtimes once they are ready, and we won’t need .mjs there.

With current WASI target you can use generic tools for .wasm <-> .ts interop, because we only provide wasm-level interop limited to number types.

[Edoardo Luppi]

Thanks!
Maybe related question: let's say I'm targeting WASI, I'm developing for the Component Model, and I want to deploy that binary on Node.js. Because of the WASI spec not being complete yet, I find out I need a feature the Node.js offers natively, and thus I need to step outside of WASI to interact with some JS API, would that be possible?

[Svyatoslav Kuzmich [JB]]

Yes, you can define any custom WIT inteface and implement it via JS in Node.js

[Edoardo Luppi]

So basically that means I can't use external declarations like what I'd be able to do in wasmJs, correct?

[Edoardo Luppi]

Just trying to solve my doubts here: will the Component Model be available for both the Wasm targets, or just for the WASI one?

[Svyatoslav Kuzmich [JB]]

Component Model will be initially in wasmWasi target.
wasmJs target relies on a tighter integration with JS than components can currently allow, so it will remain as “core Wasm + JS” for some time. But I think it would be great to provide an ability to use components from a non-component Wasm.

[Edoardo Luppi]

Sounds good! Thanks!