Drop the WASM_BINDGEN wasmExports namespace import for ESM integration - #27676
Merged
Conversation
wasm-bindgen 0.2.128 binds the asmjs-mangled per-export identifiers directly instead of reading wasmExports[...] inline, so the aggregate namespace import added in emscripten-core#27208 is no longer needed. Bump the pinned wasm-bindgen to 0.2.128. Fixes emscripten-core#27658
sbc100
approved these changes
Sep 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This removes the
WASM_ESM_INTEGRATION && WASM_BINDGENnamespace import of the wasm module added in #27208, resolves #27658.wasm-bindgen 0.2.128 no longer reads
wasmExports[...]inline in its emscripten glue; it binds the asmjs-mangled identifiers thatassignWasmExportsalready provides for every export (wasm-bindgen/wasm-bindgen#5270), so the aggregate object is not needed.import * as wasmExportsfromsrc/postamble.js, leaving the plainvar wasmExportsdeclaration for all modes.cargo addcalls, CircleCI install).test_wasm_bindgen_tsd_multi_returnnow asserts the correct public surface: only wasm-bindgen's unwrapping wrappermulti_value_return(): numberis typed, and the raw multi-valueResultABI export_multi_value_returnstays internal. With 0.2.127 the raw export leaked intoWasmModule, which is what the old[number, number, number]assertion was matching.All
test_wasm_bindgen_*tests pass against wasm-bindgen 0.2.128.Made with AI assistance under my review