Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[js-api] Ambiguity in WebAssembly.instance() importObject requirement with JS builtins imports

Open
#2,102 1 comment 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
45/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Stale
Tech stack
javascript, wasm
Domain
api, documentation

Research direction

Start with the quoted WebAssembly JS-API rule for WebAssembly.Instance() and compare how builtin imports such as wasm:js-string are handled in Firefox, Chrome, and Safari. Done means the specification explicitly defines whether builtin-satisfied imports require a user-supplied importObject and removes the cross-implementation ambiguity.

Written by the indexing model from the issue text.

Description

The WebAssembly JS-API specification currently states that WebAssembly.Instance() must throw if importObject is undefined while the module declares imports. However, modules that only import JS builtins (for example from the wasm:js-string namespace) do not require an importObject.

The spec text does not clearly define this exception, which leads to inconsistent behavior across implementations. In particular, Firefox currently throws a TypeError in this situation, while Chrome (and I believe Safari) do not.

Currently the spec states

If module.imports is not empty, and importObject is undefined, throw a TypeError exception.

I think the spec should explicitly state that imports satisfied by builtins such as wasm:js-string do not require a user-supplied importObject, even if module.imports is non-empty.

Dominant language
WebAssembly
Stars
3.5k
Forks
539
Avg merge
2d 1h
Merged PRs (30d)
13

Getting set up

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.

More from WebAssembly/spec

All issues in WebAssembly/spec

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.