Will Vite 7's ESM-only switch break my build?
Choose whether to adopt Vite 7 now or defer based on its ESM-only distribution, dropped Node 18 support, and downstream plugin/framework compatibility, especially for teams with mixed CJS tooling and older CI images.
Blockers
- Requires runtime/nodejs-20 20.19+ (require(esm) without flag needed for CJS interop)
- Requires runtime/nodejs-22 22.12+ (require(esm) without flag needed for CJS interop)
- package/vite-7 incompatible with runtime/nodejs-18: Node 18 dropped — no require(esm) support
- ESM-only distribution — CJS bundle removed
- esbuild no longer a direct dependency
- Sass legacy API support removed
- module-resolution format sniffing removed
- runtime/nodejs-18 — EOL 2025-04-30, successor: runtime/nodejs-20
Who this is for
- small-team
- enterprise
- monorepo
- low-ops
- cost-sensitive
Candidates
Adopt Vite 7 now on a fully upgraded Node baseline
Vite 7 is officially ESM-only and requires Node.js 20.19+ or 22.12+. The Vite 7 announcement says those minimums were chosen so Node supports `require(esm)` without a flag, which lets the Vite JavaScript API still be required from CJS modules on supported runtimes.
When to choose
Best for small-team + low-ops teams, or enterprise + monorepo teams, that have already standardized local dev and CI on Node.js 20.19+ or 22.12+, use mostly mainstream framework starters and Vite plugins, and want to absorb the Node runtime upgrade and bundler upgrade in one change. Choose this when mixed CJS tooling is limited to consuming Vite's JS API rather than relying on older Node 18 images or deprecated Vite internals.
Tradeoffs
This moves you onto the Vite 7 behavior model immediately and avoids staying on a runtime floor that Vite no longer supports. The cost is that you must validate the migration-guide changes that can affect downstream tooling, including the removal of Sass legacy API support, changed CommonJS interop behavior, removal of module-resolution format sniffing, preserved `require` calls for externalized modules, and the fact that `esbuild` is no longer a direct Vite dependency.
Cautions
Do not treat a generic Node 20 label as sufficient: Vite 7 explicitly requires Node.js 20.19+ or 22.12+. As of 2026-03-16, the current Vite releases page shows Vite 7 is on the previous-major support line, with important fixes and security patches backported to the latest supported Vite 7 minor while regular patches go to the current major. Audit plugins that call `transformWithEsbuild` or assume old CJS interop and package-resolution heuristics before cutting over.
Upgrade Node and CI first, then move to Vite 7 in a second step
The official Node.js 20.19.0 release enabled `require(esm)` by default on the Node 20 line, and Vite 7's official announcement ties its new minimum Node range directly to that change. This makes a staged runtime-first migration the cleanest option when your blocker is CI images, internal CLIs, or mixed CJS glue code rather than Vite app code itself.
When to choose
Best for enterprise + monorepo teams, or cost-sensitive + monorepo teams, where older CI images, pinned container bases, or internal build scripts still assume Node 18 or older Node 20 minors. Choose this when you want to separate the operational work of updating runners, Docker images, and package-manager environments from the application-facing Vite 7 migration.
Tradeoffs
This reduces blast radius by turning one risky upgrade into two smaller ones. The downside is extra coordination and a temporary period where you are paying the migration cost without yet getting the Vite 7 package and config behavior changes.
Cautions
A staged plan only works if the first phase is real and bounded. Use exact Node minimums from Vite 7, not broad major-version wording, and verify all CI images, build caches, and local version managers converge on the same floor. Once the runtime is upgraded, re-check the Vite migration guide for plugin and package-resolution assumptions that can still break even after Node is fixed.
Defer on the latest supported Vite 6 line while clearing ecosystem blockers
Vite 6 officially supports Node.js 18, 20, and 22+, and as of 2026-03-16, the current Vite releases page shows the latest Vite 6 minor still receives security backports. This is the containment path for teams whose framework/plugin stack or CI estate is not ready for Vite 7's Node floor and migration changes.
When to choose
Best for enterprise + monorepo teams with verified blockers such as Node 18-based CI images, plugins that still assume direct `esbuild` availability, packages that depend on Vite's removed format-sniffing behavior, or code affected by the new CommonJS interop rules. Choose this only when the blocker is concrete and documented, and when you have an explicit upgrade backlog to remove it.
Tradeoffs
This minimizes immediate delivery risk and lets older environments keep working while you audit framework starters, tests, and plugins. The downside is that you remain on an older major where support is narrower, Node 18 is already EOL at the platform level, and you still owe both the runtime upgrade and the Vite 7 migration later.
Cautions
This should be treated as a temporary hold, not a long-term steady state. Node's official EOL page lists Node 18 as End-of-Life, and Vite's releases policy says older majors only receive limited backports. Stay on the latest supported Vite 6 minor, and use the deferral period to inventory exactly which dependencies fail under the Vite 7 migration guide rather than postponing without a blocker list.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Will Vite 7's ESM-only switch break my build?"