[vitest-pool-workers] Fix dynamic import() in entrypoint and DO handlers

[penalosa]

Fixes #12924.
Fixes #5387.

Dynamic import() inside exports.default.fetch(), SELF.fetch(), or Durable Object handlers would hang and fail with "Cannot perform I/O on behalf of a different Durable Object". The module runner's transport — which communicates over a WebSocket owned by the runner DO — was being invoked from a different DO context.

The fix uses the onModuleRunner hook in vitest/worker's init() to patch the module runner's transport.invoke(), routing all calls through runInRunnerObject(). This ensures module resolution always happens in the runner DO's I/O context, regardless of where the import() originates.

Includes a regression fixture (fixtures/vitest-pool-workers-examples/dynamic-import/) covering both the entrypoint path (#12924) and the DO path (#5387).

---

• Tests
  • Tests included/updated
  • Automated tests not possible - manual testing has been completed as follows:
  • Additional testing not necessary because:
• Public documentation
  • Cloudflare docs PR(s):
  • Documentation not necessary because: internal fix, no user-facing config change

---

[changeset-bot]

🦋 Changeset detected

Latest commit: 1ab29ab

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

[github-actions]

✅ All changesets look good

[ask-bonk]

Review posted successfully on PR #13056. Here's a summary of what I found:

1. Unused imports in test file — runDurableObjectAlarm and runInDurableObject are imported but never used in dynamic-import.test.ts. Posted a suggestion to clean up the import line.

2. Inaccurate comment reference — A comment in packages/vitest-pool-workers/src/worker/index.ts:209 says "transport patch in entrypoints.ts" but the transport patch (onModuleRunner) is actually in index.ts itself. entrypoints.ts has a different mechanism (importModule). Posted a suggestion to fix the reference.

The core fix itself — using onModuleRunner to patch transport.invoke() with runInRunnerObject() — looks correct and well-targeted for the cross-DO I/O context issue.

github run

[workers-devprod]

Codeowners approval required for this PR:

• ✅ @cloudflare/wrangler

Show detailed file reviewers

[pkg-pr-new]

create-cloudflare

npm i https://pkg.pr.new/create-cloudflare@13056

@cloudflare/kv-asset-handler

npm i https://pkg.pr.new/@cloudflare/kv-asset-handler@13056

miniflare

npm i https://pkg.pr.new/miniflare@13056

@cloudflare/pages-shared

npm i https://pkg.pr.new/@cloudflare/pages-shared@13056

@cloudflare/unenv-preset

npm i https://pkg.pr.new/@cloudflare/unenv-preset@13056

@cloudflare/vite-plugin

npm i https://pkg.pr.new/@cloudflare/vite-plugin@13056

@cloudflare/vitest-pool-workers

npm i https://pkg.pr.new/@cloudflare/vitest-pool-workers@13056

@cloudflare/workers-editor-shared

npm i https://pkg.pr.new/@cloudflare/workers-editor-shared@13056

wrangler

npm i https://pkg.pr.new/wrangler@13056

commit: 1ab29ab

[penalosa]

/bonk fix the formatting in this PR and commit the result

[ask-bonk]

Good fix. The core approach is sound: onModuleRunner is a documented vitest VitestWorker hook (vitest v4.1.0 src/runtime/workers/types.ts), and patching transport.invoke() to route through runInRunnerObject() correctly ensures module resolution always happens in the runner DO's I/O context.

A few observations:

The transport is private readonly on ModuleRunner — the PR works around this by casting to a structural type at runtime (as { transport?: { invoke?: ... } }). This is fine pragmatically, but it's worth noting this is reaching into vite internals. If a future vite version changes the transport architecture (e.g., making it truly inaccessible or restructuring NormalizedModuleRunnerTransport), this patch would silently become a no-op due to the optional chaining guard. That's actually a reasonable degradation path, but it might be worth adding a __console.warn if the guard fails (i.e., runner.transport?.invoke is falsy), so the team gets early signal when/if vite changes break this.

Agreeing with other reviewers on two minor issues:

1. The comment on line 208-209 says "transport patch in entrypoints.ts" but the onModuleRunner hook is in this same file (index.ts). entrypoints.ts has the importModule() wrapper which is a separate mechanism. The author already acknowledged this via the reply about the comment never being accurate, but the new text should still be corrected.

2. runDurableObjectAlarm and runInDurableObject are imported but unused in dynamic-import.test.ts. This will likely fail lint (@typescript-eslint/no-unused-vars).

Neither blocks merging.

[ask-bonk]

Review posted on PR #13056 with approval. Here's a summary of my findings:

The fix is correct and well-targeted. It uses vitest's onModuleRunner hook (a documented VitestWorker API in vitest v4.1.0) to patch transport.invoke() so all calls go through runInRunnerObject(). This ensures module resolution from dynamic import() always happens in the runner DO's I/O context, regardless of which DO context triggered it.

Three comments posted:

1. Unused imports in dynamic-import.test.ts — runDurableObjectAlarm and runInDurableObject are imported but never used. Will fail lint.

2. Inaccurate comment reference at line 208-209 — says "transport patch in entrypoints.ts" but the onModuleRunner hook is in index.ts. Suggested correcting to "onModuleRunner transport patch below".

3. Private transport access — ModuleRunner.transport is private readonly in vite's source. The type assertion bypasses this at runtime. The optional chaining provides safe degradation, but suggested adding a __console.warn if the guard fails so the team gets early signal if a future vite upgrade breaks the patch.

github run