Vite 7 goes ESM-only with a baseline browser target

Vite 7 represents a decisive shift in how modern frontend applications are built and shipped for the web. By going ESM-only on the Node.js side and adopting a Baseline Widely Available browser target by default, the toolchain now embraces the realities of today’s JavaScript ecosystem rather than carrying the weight of legacy environments. For teams that already live in a modern stack, these changes mostly unlock cleaner configs, smaller bundles, and faster builds.

At the same time, these shifts are not purely cosmetic. Requiring recent Node.js versions and assuming a higher browser baseline forces organizations to re-evaluate their CI images, hosting environments, and support matrices. Migrating to Vite 7 is straightforward in many cases, but it does require conscious decisions about which platforms to support and how aggressively to lean into modern platform features.

From “modules” to Baseline Widely Available

Previous versions of Vite used a modules target that essentially meant “browsers with native ES modules, dynamic import, and import.meta.” That translated to fairly old versions of Chrome, Firefox, Safari, and Edge, which kept transpilation and polyfill requirements conservative. In Vite 7, this target is replaced with baseline-widely-available, aligning directly with the Baseline initiative that tracks which web platform features are consistently supported across core browsers for at least about 30 months.​​​​

Concretely, the default build.target jumps from the older ESM thresholds to much newer minimum versions: Chrome 107 instead of 87, Edge 107 instead of 88, Firefox 104 instead of 78, and Safari 16.0 instead of 14.0.​​​​ This mirrors the Baseline Widely Available list as of May 2025, meaning the default set of browsers is tied to a transparent, time-based standard rather than an opaque “modern enough” heuristic.

This change has two major implications. First, it gives teams a predictable cadence: with each major Vite release, the default baseline will move forward in step with Baseline’s widely-available window. Second, it reduces the need to over-transpile for long-obsolete browsers, which in practice shrinks bundles, speeds up parsing, and makes it safer to lean on newer JavaScript and DOM features without sprinkling custom compatibility checks throughout the codebase.​​​​

Vite 7 Goes ESM-only on Node.js

On the server side, Vite 7 is now shipped as ESM-only. To support this, the team officially dropped Node.js 18 and requires Node.js 20.19+ or 22.12+.​​​​ These versions of Node include full support for require(esm) without feature flags, which lets CommonJS consumers continue to require() Vite’s ESM-distributed API where needed. Under the hood, this simplifies how Vite is packaged and how it interoperates with native module semantics.

This ESM-only move is part of a broader ecosystem trend. Many modern libraries are converging on ESM as the primary or sole distribution format, taking advantage of tree-shaking, clearer static analysis, and closer alignment with what browsers natively execute.​​​​ For Vite, whose raison d’être is to bridge dev-time and run-time behavior, matching the browser’s module system at every layer reduces complexity and improves performance.

For existing codebases, the immediate tasks are mostly operational: update Node in local environments, Docker images, and CI runners, and ensure any scripts or tooling that depended on older Node versions are upgraded. In most cases Vite’s public API and CLI usage remain familiar, but the underlying runtime assumptions are cleaner and more future-proof.

What Baseline Browser Targeting Really Changes

Baseline targeting is more than a new label in vite.config.ts. By aligning to Baseline Widely Available, Vite 7 can assume that a significant set of modern language and platform features are present in every supported browser. That list includes advanced JavaScript syntax like top-level await, private class fields, logical assignment operators, and stable ES2022 constructs, along with a wide range of DOM and Web API improvements.​​​​

The practical upshot is that fewer transforms are necessary in production builds. When TypeScript or modern JavaScript features can be emitted as-is for the targeted browsers, bundlers like Vite can generate smaller, more readable output. That leads to faster download times, quicker parsing, and more efficient execution, which is especially important on lower-powered mobile devices where every kilobyte and CPU cycle matters.​​​​

At the same time, the Baseline approach clarifies responsibilities around compatibility. Vite’s default bundle covers syntax transformations appropriate for the chosen targets but does not automatically inject polyfills for missing APIs.​​​​ If your audience includes browsers outside the baseline or relies on APIs not guaranteed by Baseline, it becomes your job to introduce the appropriate polyfills or to widen your build.target configuration and consider using plugins like @vitejs/plugin-legacy for truly old environments.

Configuring Targets and Handling Legacy Browsers

While the new baseline-widely-available target is the default, it is not mandatory. Vite 7 still allows you to specify custom targets via build.target, down to es2015 for syntax-level transformations.​​​​ Teams that must support corporate environments with frozen browser versions, kiosk systems, or regions with slower upgrade cycles can override the baseline and transpile more aggressively.

There is, however, a lower limit driven by how Vite itself operates. Even for custom targets, Vite’s dev and build pipelines rely on native ESM, dynamic import, and import.meta, which requires at least Chrome 64, Firefox 67, Safari 11.1, and Edge 79.​​​​ For browsers below those thresholds, the recommended approach is not to twist Vite into supporting them directly, but to rely on legacy bundles produced via @vitejs/plugin-legacy. That plugin generates extra chunks and ES language polyfills that are conditionally loaded on non-ESM browsers.

In practice, this creates a clean separation: primary builds are optimized for the Baseline (or your chosen modern target), while legacy support becomes an explicit progressive enhancement step. That fits well with the way many teams now think about their support matrix, optimize for the modern majority, and provide a carefully scoped fallback path for users on outdated hardware or locked-down platforms.​​​​

Performance and Developer Experience Benefits

The combination of ESM-only distribution and a modern Baseline target yields notable performance benefits. First, with ESM throughout the stack, bundlers can perform more effective tree-shaking and dead-code elimination, reducing bundle size. They can also avoid compatibility layers that were necessary when juggling CJS and ESM formats, which in turn simplifies configuration and accelerates cold starts.​​​​

Second, by targeting browsers that already support advanced language features, Vite has less work to do during both dev and build phases. Fewer Babel-like transforms mean faster rebuilds, quicker hot module replacement cycles, and less over when handling large codebases. This ties into Vite’s broader ecosystem evolution, including experimental support for Rolldown, a Rust-based bundler that aims to further cut build times while integrating tightly with Vite’s pipeline.​​​​

Finally, predictable Baseline-based updates offer planning advantages for larger organizations. Knowing that each major release will shift the minimum browsers by roughly a 30-month window lets teams schedule deprecation of old platforms well in advance. Documentation, QA matrices, and customer-facing support policies can all be aligned to that timeline rather than updated ad hoc when some tool silently drops support for an older browser.

Migration Considerations for Existing Projects

For teams coming from Vite 6, the official migration guide highlights two main breaking areas: the Node.js requirement bump and the default browser target change.​​​​ The first step is ensuring all environments run Node 20.19+ or 22.12+, including local machines, CI runners, and production build servers. This alone may require updates to base Docker images or build agents, particularly in enterprises that pin long-term support distributions.

Next, you should review your project’s browser support policy. If your real-world audience already aligns with or exceeds the new Baseline, the migration may be nearly seamless, your builds will just get a bit leaner and faster. If you still need to support older browsers, you have a choice: explicitly set a broader build.target and rely on transpilation and legacy plugins, or draw a firm line and officially drop those environments from your compatibility matrix.

It is also wise to audit your dependencies and plugins. Most actively maintained Vite plugins have already adapted to the ESM-only world, but if your toolchain includes older, unmaintained packages, they may still rely on CommonJS-only assumptions. In many cases, Node’s modern ESM interop is sufficient to bridge the gap, but testing your dev server, build, and SSR pipelines end-to-end before flipping everything to Vite 7 in production is crucial.

Vite 7’s move to ESM-only distribution and a Baseline Widely Available browser target reflects where the web platform has been ing for years: fewer compromises for obsolete environments and tighter alignment between what we write, what bundlers emit, and what browsers natively understand. For most modern projects, the change is a net win, unlocking smaller bundles, simpler configurations, and a clearer mental model of what “supported platforms” really means.

At the same time, these shifts put the onus on teams to be explicit about their support strategies. Rather than relying on conservative defaults that quietly accommodate outdated browsers, Vite 7 asks you to opt in to that complexity when you truly need it. If you are ready to focus on the modern web, on ESM, Baseline features, and predictable compatibility windows, Vite 7’s new defaults provide a strong, future-focused foundation.