[vitest-pool-workers] Allow .wasm files to be imported as .wasm?module#11094
Merged
penalosa merged 4 commits intoMay 7, 2026
Merged
Conversation
🦋 Changeset detectedLatest commit: 9fa1d9b The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
create-cloudflare
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-pool-workers
@cloudflare/workers-editor-shared
@cloudflare/workers-utils
wrangler
commit: |
5b49f2b to
d964686
Compare
Contributor
|
Codeowners approval required for this PR:
Show detailed file reviewers
|
d964686 to
aac0d29
Compare
Contributor
|
Codeowners approval required for this PR:
Show detailed file reviewers
|
Contributor
|
Codeowners approval required for this PR:
Show detailed file reviewers
|
92330a5 to
ec1ed40
Compare
f2b25f9 to
e512891
Compare
Externalize .wasm?module specifiers through the fallback service and normalize Vite @fs paths so dependency-local WASM modules resolve under the Vitest pool.
e512891 to
9fa1d9b
Compare
penalosa
reviewed
May 5, 2026
penalosa
approved these changes
May 7, 2026
Contributor
|
Codeowners approval required for this PR:
Show detailed file reviewers |
workers-devprod
approved these changes
May 7, 2026
workers-devprod
left a comment
Contributor
There was a problem hiding this comment.
Codeowners reviews satisfied
Merged
5 tasks
tahmid-23
added a commit
to tahmid-23/workers-sdk
that referenced
this pull request
Jun 5, 2026
…deps
Previously, only literal `await import("./x.wasm?module")` specifiers were
rewritten through the static analysis path added in cloudflare#11094. CommonJS
dependencies that use `require("./x.wasm?module")` reach the module-fallback
service at runtime, where the `?module` suffix went unhandled. The fallback
either failed with `No such module "<abs>/x.wasm?module"` or, when a
CompiledWasm rule was configured, attempted to evaluate the WebAssembly bytes
as JavaScript.
These `require()`s work in deployed workers because esbuild's bundler
statically rewrites them into ES dynamic imports. vitest-pool-workers'
Vite-based pipeline doesn't do that rewrite and instead defers to the
module-fallback at runtime.
The module-fallback now strips `?module` from the resolved target and
synthesizes a CommonJS wrapper that re-`require`s the underlying `.wasm` by
absolute path, exposing it on `default` to match what workerd produces for
CompiledWasm modules.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
tahmid-23
added a commit
to tahmid-23/workers-sdk
that referenced
this pull request
Jun 8, 2026
…deps
Previously, only literal `await import("./x.wasm?module")` specifiers were
rewritten through the static analysis path added in cloudflare#11094. CommonJS
dependencies that use `require("./x.wasm?module")` reach the module-fallback
service at runtime, where the `?module` suffix went unhandled. The fallback
either failed with `No such module "<abs>/x.wasm?module"` or, when a
CompiledWasm rule was configured, attempted to evaluate the WebAssembly bytes
as JavaScript.
These `require()`s work in deployed workers because esbuild's bundler
statically rewrites them into ES dynamic imports. vitest-pool-workers'
Vite-based pipeline doesn't do that rewrite and instead defers to the
module-fallback at runtime.
The module-fallback now strips `?module` from the resolved target and
synthesizes a CommonJS wrapper that re-`require`s the underlying `.wasm` by
absolute path, exposing it on `default` to match what workerd produces for
CompiledWasm modules.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
tahmid-23
added a commit
to tahmid-23/workers-sdk
that referenced
this pull request
Jun 15, 2026
…deps
Previously, only literal `await import("./x.wasm?module")` specifiers were
rewritten through the static analysis path added in cloudflare#11094. CommonJS
dependencies that use `require("./x.wasm?module")` reach the module-fallback
service at runtime, where the `?module` suffix went unhandled. The fallback
either failed with `No such module "<abs>/x.wasm?module"` or, when a
CompiledWasm rule was configured, attempted to evaluate the WebAssembly bytes
as JavaScript.
These `require()`s work in deployed workers because esbuild's bundler
statically rewrites them into ES dynamic imports. vitest-pool-workers'
Vite-based pipeline doesn't do that rewrite and instead defers to the
module-fallback at runtime.
The module-fallback now strips `?module` from the resolved target and
synthesizes a CommonJS wrapper that re-`require`s the underlying `.wasm` by
absolute path, exposing it on `default` to match what workerd produces for
CompiledWasm modules.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
tahmid-23
added a commit
to tahmid-23/workers-sdk
that referenced
this pull request
Jun 15, 2026
…deps
Previously, only literal `await import("./x.wasm?module")` specifiers were
rewritten through the static analysis path added in cloudflare#11094. CommonJS
dependencies that use `require("./x.wasm?module")` reach the module-fallback
service at runtime, where the `?module` suffix went unhandled. The fallback
either failed with `No such module "<abs>/x.wasm?module"` or, when a
CompiledWasm rule was configured, attempted to evaluate the WebAssembly bytes
as JavaScript.
These `require()`s work in deployed workers because esbuild's bundler
statically rewrites them into ES dynamic imports. vitest-pool-workers'
Vite-based pipeline doesn't do that rewrite and instead defers to the
module-fallback at runtime.
The module-fallback now strips `?module` from the resolved target and
synthesizes a CommonJS wrapper that re-`require`s the underlying `.wasm` by
absolute path, exposing it on `default` to match what workerd produces for
CompiledWasm modules.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
emily-shen
added a commit
to tahmid-23/workers-sdk
that referenced
this pull request
Jun 16, 2026
…deps
Previously, only literal `await import("./x.wasm?module")` specifiers were
rewritten through the static analysis path added in cloudflare#11094. CommonJS
dependencies that use `require("./x.wasm?module")` reach the module-fallback
service at runtime, where the `?module` suffix went unhandled. The fallback
either failed with `No such module "<abs>/x.wasm?module"` or, when a
CompiledWasm rule was configured, attempted to evaluate the WebAssembly bytes
as JavaScript.
These `require()`s work in deployed workers because esbuild's bundler
statically rewrites them into ES dynamic imports. vitest-pool-workers'
Vite-based pipeline doesn't do that rewrite and instead defers to the
module-fallback at runtime.
The module-fallback now strips `?module` from the resolved target and
synthesizes a CommonJS wrapper that re-`require`s the underlying `.wasm` by
absolute path, exposing it on `default` to match what workerd produces for
CompiledWasm modules.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
emily-shen
added a commit
to tahmid-23/workers-sdk
that referenced
this pull request
Jun 29, 2026
…deps
Previously, only literal `await import("./x.wasm?module")` specifiers were
rewritten through the static analysis path added in cloudflare#11094. CommonJS
dependencies that use `require("./x.wasm?module")` reach the module-fallback
service at runtime, where the `?module` suffix went unhandled. The fallback
either failed with `No such module "<abs>/x.wasm?module"` or, when a
CompiledWasm rule was configured, attempted to evaluate the WebAssembly bytes
as JavaScript.
These `require()`s work in deployed workers because esbuild's bundler
statically rewrites them into ES dynamic imports. vitest-pool-workers'
Vite-based pipeline doesn't do that rewrite and instead defers to the
module-fallback at runtime.
The module-fallback now strips `?module` from the resolved target and
synthesizes a CommonJS wrapper that re-`require`s the underlying `.wasm` by
absolute path, exposing it on `default` to match what workerd produces for
CompiledWasm modules.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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
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.
When loading WASM in module-fallback.ts in vitest-pool-workers, this change trims off a
?modulesuffix if provided from the module file path. Similar behavior is handled in vite-plugin-cloudflare, where it will trim this suffix.I ran into an issue using Cloudflare D1 with Prisma since the client generated using
included an import
import("./query_engine_bg.wasm?module")which could be handled runningwrangler devbut couldn't be handled by vitest-pools-workers since it would fail to resolve the module.A catch with this is if someone is trying to literally import a WASM file with a
.wasm?moduleextension on disk, then it can't be loaded this way.