Open
Description
Hi,
I'm experimenting with building WASM components with emscripten. I'm using wit-bindgen to generate C code from a wit
file, then compile everything with emcc
.
After that I run wasm-tools component new emcc-output.wasm -o component.wasm
to create the component and finally wasmtime run --invoke 'error-message(-6)' component.wasm
to run the code.
The problem is that WIT functions are kebab-case and this is currently not allowed in emscripten, see https://github.com/emscripten-core/emscripten/blob/main/tools/emscripten.py#L575
Using this .wit
world root {
export error-message: func(error-code: s32) -> string;
}
produces the error
emcc: error: invalid export name: cabi_post_error-message
For testing I patched out the check and everything seems to be working. Maybe you could allow dashes in export names for STANDALONE_WASM
or PURE_WASI
?
Metadata
Metadata
Assignees
Labels
No labels
Activity
sbc100 commentedon May 27, 2025
The problem is that we create corresponding JS function for each of these function exports and JS symbols cannot contains hyphens like this.
How are JS users supposed to invoke these symbols? I see a couple of options but I'm not sure either of then is great:
wasmExports
map that allows string access to all wasm exports. I've been hoping to remove the use of this global with the work I've been doing onWASM_ESM_INTEGRATION
since using this kind of prevents a lot of DCE efforts (since it doesn't express dependencies via the module graph).cabi_post_error-message
would be exposed ascabi_post_error_message
.I'm not sure I like either of these options.
I suppose in the ESM integration world we would do something kind of name mangled internally and then re-export via the original name. e.g.
This would at least give the user-faces JS module the same shaped symbols as the internal wasm module, but it still has the problem that is not very consume via normal
import
statements.peterhirn commentedon May 27, 2025
As far as I understand WASM components are not meant to be called directly by JS, but rely on some tooling like jco. That's why I'm thinking the export function name check could be relaxed when there is no JS generated by emscripten (eg.
STANDALONE_WASM
or similar).Looking at the examples in the documentation JS Language Support for Components they convert kebab-case to camelCase in jco.
sbc100 commentedon May 27, 2025
Ah yes, if we are not generating JS I don't think we need this check. Good point.
Allow arbitrary export names when not generating JS output
Allow arbitrary export names when not generating JS output