WebAssembly / WebAssembly/component-model

Importing console_log should not break the WebAssembly Compoenent Model

Open
#634 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
WebAssembly
Stars
1.4k
Forks
130
Avg merge
2d 1h
Merged PRs (30d)
15

Description

https://github.com/bytecodealliance/wasm-tools/issues/2483

From what I can see, the WIT is fine and wasm-tools is doing the right thing, but the WAT being passed to watToWit does not match the naming scheme wasm-tools expects for the specified WIT interface. Specifically, wasm-tools expects an import named "console-log" from a module named "env" based on the declared name in the WIT file. Instead, it's finding an import named "console_log" from the module named "env" and doesn't know what to do with it.

WIT is intended to provide a human-readable representation of the Component Model type system, which does not cover every possible existing ABI and naming convention used in Wasm modules that exist in the wild. The expectation is that the module author (or binding generator) will have the Component Model "canonical" ABI and naming convention in mind when creating the application, which may require source code modifications.

I do recall there was a plan to eventually support other (i.e. "non-canonical") ABIs and/or naming conventions in the Component Model, but I'm not aware of any existing support for that in the specification or in wasm-tools.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked wasm-tools issue 2483 and compare the WIT interface name with the env/console_log import described here. Determine whether the Component Model specification or wasm-tools defines support for non-canonical naming conventions; the issue is complete only when the expected behavior and scope of that support are decided.

Written by the indexing model from the issue text.

Assessment

Tech stack
wasm
Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.