feat(wasm): support inlining wasm binaries with the ?inline query - #1909
Conversation
This comment was marked as off-topic.
This comment was marked as off-topic.
e93a071 to
80cadfa
Compare
80cadfa to
ebd1d43
Compare
|
no documents about inline feature in wasm chapter? |
The resolve hook read an existing issuer query off the request before appending a new one, but appended unconditionally. Requests reaching the hook never carry that query, so drop the fallback.
The inline loader rule was registered regardless of the wasm mode, so `wasm: false` still inlined `?inline` imports while leaving plain `.wasm` imports alone. Skip the rule and keep the original specifiers instead.
Absolute issuer paths ended up in the generated module identifiers of bundleless output, which made builds depend on the source directory.
Deploying rslib with
|
| Latest commit: |
ddd5cb8
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://53a9a4bc.rslib.pages.dev |
| Branch Preview URL: | https://elecmonkey-wasm-inline.rslib.pages.dev |
|
I suggest merging the current version, since |
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ddd5cb874f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| : request.replace( | ||
| /(?=#|$)/, | ||
| `${request.includes('?') ? '&' : '?'}${WASM_INLINE_ISSUER_QUERY}=${encodeURIComponent(importer)}`, | ||
| ); |
There was a problem hiding this comment.
When bundle: false and an inline Wasm module itself imports another Wasm module such as ./dep.wasm, appending this issuer query changes the request so it no longer ends with .wasm. Consequently, createWasmPreserveExternal and the Wasm bailout in composeBundlelessExternalConfig both miss it; the generic asset logic then rewrites the request to a JavaScript extension, without preserving or compiling the dependency. The resulting output imports a nonexistent .js file, so classification should ignore the internal issuer query.
Useful? React with 👍 / 👎.
| const issuer = | ||
| inlineIssuer !== null && typeof outBase === 'string' | ||
| ? path.resolve(outBase, inlineIssuer) | ||
| : contextInfo.issuer; |
There was a problem hiding this comment.
With bundle: false and redirect.js.path: false, an inline Wasm file in a nested directory cannot resolve its relative JavaScript imports after being folded into its importer. For example, if src/index.js imports src/nested/read.wasm?inline and that binary imports ./meta.js, the generated code is placed in dist/index.js, but the generic externalizer honors the disabled redirect and leaves ./meta.js unchanged instead of producing ./nested/meta.js. Synthetic Wasm dependencies need mandatory rebasing because their output location changed independently of the user's redirect setting.
Useful? React with 👍 / 👎.
Summary
Support importing small WebAssembly binaries with
?inlineto embed them directly into JavaScript.The binary is instantiated with top-level
awaitand exposes the exports declared by the WebAssembly module as ESM exports. This requires ESM output.In bundleless builds, the binary is embedded into each importing JavaScript file. WebAssembly imports are resolved as module dependencies.