Vite 8 breaks importing pg in Vitest

[hansottowirtz]

What versions & operating system are you using?

System:
OS: macOS 26.3
CPU: (10) arm64 Apple M1 Pro
Memory: 84.08 MB / 32.00 GB
Shell: 5.9 - /opt/homebrew/bin/zsh
Binaries:
Node: 22.22.0 - /Users/otto/.volta/tools/image/node/22.22.0/bin/node
Yarn: 4.3.0 - /Users/otto/.volta/tools/image/yarn/4.3.0/bin/yarn
npm: 10.9.4 - /Users/otto/.volta/tools/image/node/22.22.0/bin/npm
pnpm: 10.28.2 - /Users/otto/.volta/tools/image/pnpm/10.28.2/bin/pnpm
Deno: 1.45.5 - /Users/otto/.deno/bin/deno
Watchman: 2026.01.12.00 - /opt/homebrew/bin/watchman
npmPackages:
@cloudflare/vite-plugin: ^1.29.1 => 1.30.0
@cloudflare/vitest-pool-workers: ^0.13.3 => 0.13.3
@cloudflare/workers-types: ^4.20260317.1 => 4.20260317.1
wrangler: ^4.75.0 => 4.76.0

Please provide a link to a minimal reproduction

https://github.com/hansottowirtz/cf-workers-pg-vitest-repro

Describe the Bug

Using Vitest pool workers with Vite 8 breaks importing pg in tests.
Here is a repro: https://github.com/hansottowirtz/cf-workers-pg-vitest-repro (just run pnpm test there)

Errors are:

• strange "Cannot use import statement outside a module" issue, can be worked around by adding pg to test.deps.optimizer.ssr.include
• then, builtin node modules imported by pg are not externalized correctly, this can be worked around with the commented block in vitest.config.ts
• then, using pg causes the Cannot perform I/O on behalf of a different Durable Object. I/O objects error.
  If you want I can add it into vitest-pool-workers-examples as well, if that runs as part of CI.

Related: #12947

Please provide any relevant error logs

No response

[petebacondarwin]

Analysis: Vite 8 / Rolldown Resolver Resolves require() to ESM Entry Points

I cloned the reproduction repo and ran the tests with NODE_DEBUG=vitest-pool-workers:module-fallback to get exact module resolution traces.

The debug output reveals the root cause directly:

require("pg-protocol") relative to .../pg/lib/connection.js?mf_vitest_no_cjs_esm_shim:
  → redirect: pg-protocol/esm/index.js?mf_vitest_no_cjs_esm_shim   ← WRONG
  (should be: pg-protocol/dist/index.js)

require("pg-connection-string") relative to .../pg/lib/connection-parameters.js?mf_vitest_no_cjs_esm_shim:
  → redirect: pg-connection-string/esm/index.mjs?mf_vitest_no_cjs_esm_shim  ← WRONG

pg-protocol's esm/index.js contains import * as protocol from '../dist/index.js' — an ESM import statement. When workerd receives it with the ?mf_vitest_no_cjs_esm_shim suffix (i.e., loaded raw as CommonJS), it throws:

SyntaxError: Cannot use import statement outside a module

Root Cause: Vite 8 Rolldown Resolver Doesn't Honor isRequire for Conditional Exports

Both pg-protocol and pg-connection-string ship dual-condition exports:

{
  "exports": {
    ".": {
      "import": "./esm/index.js",
      "require": "./dist/index.js",
      "default": "./dist/index.js"
    }
  }
}

vitest-pool-workers' module-fallback server calls vite.pluginContainer.resolveId(specifier, referrer, { ssr: true, custom: { "node-resolve": { isRequire: true } } }) for require() calls. This hint is supposed to tell the resolver to prefer the "require" export condition.

In Vite 7 (esbuild/rollup-based resolver): No automatic condition was appended; conditions were exactly ["workerd", "worker", "module", "browser"]. Since none of those match "import" or "require", resolution fell to "default" → the CJS file. ✅

In Vite 8 (rolldown-based resolver): Vite 8 added getConditions() which always appends "require" or "import" to the conditions list based on the call type. So conditions for require() become ["workerd", "worker", "module", "browser", "require"] — this should prefer the CJS "require" entry.

However, the debug trace shows rolldown's resolver is still picking the "import" entry (esm/index.js) instead of "require" entry (dist/index.js) for require() calls. The isRequire: true custom option passed to resolveId is not being correctly honored by rolldown's resolver when choosing between "import" and "require" export conditions.

Vite 8 Changelog Context

Vite 8's migration guide notes: "Dependency Optimizer Now Uses Rolldown" and "Removed Module Resolution Using Format Sniffing". The switch from esbuild/rollup to rolldown changed how conditional exports are resolved, and the rolldown resolver appears to have a different (arguably incorrect) behavior when isRequire is signaled through the pluginContainer.resolveId custom options.

Where the Fix Should Go

@cloudflare/vitest-pool-workers in packages/vitest-pool-workers/src/pool/module-fallback.ts, in the viteResolve() function.

Currently:

const resolved = await vite.pluginContainer.resolveId(specifier, referrer, {
  ssr: true,
  custom: { "node-resolve": { isRequire } }
});

Since Vite 8's rolldown resolver doesn't correctly use the isRequire hint when choosing between "import" and "require" export conditions, the fallback server needs to detect and correct this. One approach:

Option A: After resolution, if isRequire=true and the resolved path points to an ESM file (.mjs extension, or a .js file in a type:module package), try to re-resolve with an explicit conditions override that places "require" before "import".

Option B: Add a post-resolution check — if the resolved file is an ESM file and the call is a require(), attempt to find the CJS sibling by re-reading the package exports map directly (bypassing the rolldown resolver).

Option C (simpler workaround in user config): Add pg, pg-protocol, and pg-connection-string to test.deps.optimizer.ssr.include so Vite pre-bundles them into a single ESM bundle before the module-fallback ever sees them. This is the workaround the issue reporter already found.

Summary of All Three Errors

1. Cannot use import statement outside a module — rolldown resolves require('pg-protocol') to esm/index.js (ESM) which is then loaded raw as CJS by workerd.

2. Node built-ins not externalized (after applying the first workaround) — Vite 8's rolldown dep optimizer doesn't automatically externalize net, tls, events, etc., when pre-bundling pg for the SSR/webworker environment. Requires explicit rolldownOptions.external config.

3. Cannot perform I/O on behalf of a different Durable Object — Once pg loads and connects via Hyperdrive, the Pool's async connection management causes TCP socket I/O to cross Durable Object context boundaries inside workerd.

Issues 1 and 2 are regressions caused by the Vite 7 → 8 switch. Issue 3 may be pre-existing or may be exposed by the different execution context that results from the workarounds for issues 1 and 2.

[astanciu]

Any updates here, or temporary workarounds?