esmExternalRequirePlugin (builtin:esm-external-require) has no effect when building through vp run

[shoya-kimura]

Summary

esmExternalRequirePlugin from Vite 8 does not take effect when building through vp run, because vp uses its own bundled Vite CLI (@voidzero-dev/vite-plus-core/dist/vite/node/cli.js) instead of the project's vite/bin/vite.js. The plugin is registered and visible in the plugin list, but the Rolldown native-layer transformation that converts CJS require() calls to ESM import statements never executes. This results in require() calls remaining in the output, which breaks deployment to ESM-only runtimes like Cloudflare Workers.

Environment

• vite-plus: v0.1.12
• vite: v8.0.0
• rolldown: v1.0.0-rc.9
• Node.js: v24.14.0 (also reproduced on v22.16.0)
• OS: Linux (Ubuntu 24.04, tested on both GitHub Actions and devcontainer)
• Target: Cloudflare Workers (ESM-only runtime)

Reproduction

Minimal vite.config.ts

import { cloudflare } from '@cloudflare/vite-plugin';
import { defineConfig, esmExternalRequirePlugin } from 'vite';

export default defineConfig({
  plugins: [
    esmExternalRequirePlugin(),
    cloudflare({
      configPath: './wrangler.jsonc',
      persistState: true,
    })
  ],
});

The project has CJS dependencies (e.g., pg / node-postgres) that use require() for Node.js builtins (events, crypto, util, dns, fs).

Steps

# 1. Build with vite directly — works correctly
rm -rf dist && npx vite build
grep -c 'require(' dist/output/index.js
# → 0

# 2. Build with vp — require() calls remain
rm -rf dist && npx vp run --filter "@my/package" build
grep -c 'require(' dist/output/index.js
# → 24

Expected Behavior

vp run ... build should produce the same output as npx vite build. Specifically, esmExternalRequirePlugin should convert all CJS require() calls for external modules into ESM import statements.

Actual Behavior

vp run ... build produces output containing 24 require() calls — Rolldown's __require() shim wrapping Node.js builtins from CJS dependencies:

var __require = /* @__PURE__ */ createRequire(import.meta.url);
// ...
__require("util")
__require("crypto")
__require("fs")
__require("dns")
__require("events")

Deploying this to Cloudflare Workers fails with:

Uncaught Error: Calling `require` for "events" in an environment
that doesn't expose the `require` function.
[code: 10021]

Root Cause Analysis

The plugin is registered but the native transform does not execute

I instrumented the buildStart hook to inspect the plugin pipeline in both code paths:

	npx vite build	npx vp run ... build
Vite CLI binary	vite@8.0.0/bin/vite.js	vite-plus-core@0.1.12/dist/vite/node/cli.js
Total plugins	45	45
builtin:esm-external-require registered	Yes	Yes
Modules transformed	622	612
Output size	1,109.01 kB	1,106.65 kB
require() calls in output	0	24

The 10-module difference (622 vs 612) corresponds exactly to the synthetic import-wrapper modules that esmExternalRequirePlugin generates when working correctly.

What differs

The only observable differences between the two code paths:

1. The Vite CLI entry point: vp uses its own bundled copy at @voidzero-dev/vite-plus-core/dist/vite/node/cli.js rather than the project's vite/bin/vite.js.
2. One extra env var: vp sets VITE_PLUS_VERSION=0.1.12.

Everything else is identical: same cwd, same NODE_ENV, same config file, same plugin count, same plugin names.

Hypothesis

esmExternalRequirePlugin registers a Rolldown builtin plugin (builtin:esm-external-require) that operates in Rolldown's native (Rust) layer. When vp's bundled Vite CLI invokes Rolldown, the builtin plugin identifier is likely not being correctly resolved or passed through to the native layer. The plugin object exists in the JavaScript plugin array (hence it shows up in buildStart introspection), but the native-side transformation that actually rewrites the require() calls is never triggered.

Workaround

Use npx vite build directly instead of vp run ... build for affected packages.

Impact

This is a build-correctness issue that is silent at build time — no warnings or errors are emitted, and the build completes successfully. The problem only manifests at deploy or runtime. Any project using vp run + esmExternalRequirePlugin + an ESM-only runtime will produce broken output.

Minimal Reproduction Repository

https://github.com/shoya-kimura/vite-plus-repro-1063

git clone https://github.com/shoya-kimura/vite-plus-repro-1063
cd vite-plus-repro-1063
pnpm install

# Works — 0 require() in output
rm -rf dist && npx vite build
grep -c 'require(' dist/vp_repro/index.js  # → 0

# Broken — 24 require() in output
rm -rf dist && npx vp run build
grep -c 'require(' dist/vp_repro/index.js  # → 24

[claude]

Analysis

Thank you for the detailed report and excellent root cause investigation.

Understanding the Issue

When vp run ... build is invoked, the flow is:

1. resolve-vite.ts resolves the vite binary via dirname(resolve('@voidzero-dev/vite-plus-core')) + cli.js, landing at @voidzero-dev/vite-plus-core/dist/vite/node/cli.js
2. Rust (packages/cli/binding/src/cli.rs) spawns node <binPath> build <args> as a subprocess
3. The bundled Vite CLI runs with its own bundled Rolldown

Root Cause Hypothesis

The most likely cause is a version mismatch between two Rolldown instances:

• Your vite.config.ts imports esmExternalRequirePlugin from vite — which resolves to your project's vite@8.0.0 (built against rolldown@1.0.0-rc.9)
• But the bundled Vite CLI in vite-plus-core@0.1.12 uses its own bundled rolldown@1.0.0-rc.10 + vite@8.0.1 (see bundledVersions in packages/core/package.json)

builtin:esm-external-require is a native Rolldown plugin: the JS-layer plugin object is created by esmExternalRequirePlugin() but the actual CJS-to-ESM transformation happens in Rolldown's Rust/native layer. If the Rolldown version that created the plugin and the Rolldown version running the build are different (mismatched native ABI or API), the plugin registers itself in the JS plugin list but the native transform never fires — which matches your observation exactly.

Key Files

• packages/cli/src/resolve-vite.ts:32-33 — resolves the vite binary path to dist/vite/node/cli.js
• packages/cli/binding/src/cli.rs:312-336 — spawns node <binPath> build <args>
• packages/core/build.ts:334-373 — bundleRolldown() rewrites @rolldown/binding-* to vite-plus/binding in release builds
• packages/core/BUNDLING.md — documents the full bundling architecture

Clarification Needed

Could you confirm:

1. How is vite installed in your project? Does your package.json have "vite": "8.0.0" as a direct dependency alongside vite-plus, or is vite only installed transitively / as an alias to vite-plus? Running node -e "console.log(require.resolve('vite'))" from your project root would confirm which vite is being resolved when the config is loaded.

2. Does removing vite@8.0.0 and using only vite-plus fix the issue? If vite in the config resolves to vite-plus (which re-exports from @voidzero-dev/vite-plus-core), both the CLI and the config would use the same bundled rolldown instance.

Is This Fixable?

Yes, and likely in one of two ways:

Option A — Align config's vite resolution to the bundled version (robust fix)

When the bundled Vite CLI loads vite.config.ts, it should ensure that import ... from 'vite' resolves to the bundled version (@voidzero-dev/vite-plus-core), not a separately-installed vite@x.y.z. This would guarantee that both the CLI and the plugin factory use the same Rolldown native binding. The bundled Vite CLI's config-loading code could intercept vite imports and redirect them to @voidzero-dev/vite-plus-core to enforce consistency.

Option B — Document the constraint and emit a warning (simpler fix)

Document that vite-plus should be the sole vite provider (installed as "vite": "npm:vite-plus@..." or via recommended setup), and that having both vite@x.y.z and vite-plus installed simultaneously with version mismatches is unsupported. A warning at build time when the bundled vite version differs from the project's installed vite version would surface this early.

Complexity

• Option A: Medium — requires patching how the bundled Vite CLI resolves modules when loading config files
• Option B: Low for the warning, zero code changes for documentation-only

Happy to investigate further once the clarifying question above is answered.