Skip to content

Add option to allow dashes "-" in export names for WASM components #24413

Open
@peterhirn

Description

@peterhirn

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?

Activity

sbc100

sbc100 commented on May 27, 2025

@sbc100
Collaborator

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:

  1. Use the mostly-internal-and-perhaps-deprecated soon 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 on WASM_ESM_INTEGRATION since using this kind of prevents a lot of DCE efforts (since it doesn't express dependencies via the module graph).
  2. Use some kind of name mangling rule. So cabi_post_error-message would be exposed as cabi_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.

import { "error-message" as _internal_error_message} from "./themodule.wasm";

... code that uses `_internal_error_message`..

export { _internal_error_message as "error-message" };

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

peterhirn commented on May 27, 2025

@peterhirn
Author

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

sbc100 commented on May 27, 2025

@sbc100
Collaborator

Ah yes, if we are not generating JS I don't think we need this check. Good point.

added 2 commits that reference this issue on May 27, 2025
7353955
1627d30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Participants

      @sbc100@peterhirn

      Issue actions

        Add option to allow dashes "-" in export names for WASM components · Issue #24413 · emscripten-core/emscripten