Default target: baseline-widely-available

What is Baseline

Baseline is a web platform compatibility standard established jointly by Google, Mozilla, Apple, and Microsoft.

When a Web API or CSS feature is marked as Baseline Widely Available, it means:

• It has been stably supported for more than 2.5 years in Chrome, Firefox, Safari, and Edge
• You can safely use it in production without polyfills or fallbacks

Starting with Vite 7, baseline-widely-available is the default build target:

// This is the default for Vite 7+, no need to write it explicitly
export default defineConfig({
  build: {
    target: "baseline-widely-available",
  },
})

What browsers does it actually cover

"Widely Available" means a feature has been stable across major browsers for a meaningful period of time. The Vite config docs expand this abstract target into concrete browser versions; when writing long-lived documentation or config, treat the current Vite docs as the source of truth rather than hard-coding old versions.

For the Vite 8 mental model, remember:

• baseline-widely-available is the default; most apps do not need to write it.
• It controls which modern syntax the build output may use; it is not a polyfill policy.
• Concrete browser versions may move as Vite and Baseline data evolve.

Comparing with a manual target

// Option 1: Baseline (recommended — keeps up with time automatically)
export default defineConfig({
  build: {
    target: "baseline-widely-available",
  },
})

// Option 2: Specific browser versions (requires manual maintenance)
export default defineConfig({
  build: {
    target: ["chrome95", "firefox95", "safari15", "edge95"],
  },
})

// Option 3: ECMAScript version
export default defineConfig({
  build: {
    target: "es2022", // build output uses ES2022 syntax features
  },
})

The advantage of Baseline: as time passes, it automatically represents "features supported by current mainstream browsers" without requiring manual updates.

Should You Change The Target?

Do not raise the target just because it looks more modern. The target affects two things:

1. Syntax lowering: whether class fields, optional chaining, top-level await, and similar syntax need transforms.
2. Build failure conditions: if source or dependencies use features that cannot be safely transformed for the target, build may fail.

Use this rule of thumb:

Library mode needs special care. Apps know their users' browsers; libraries usually do not. A library target that is too modern may prevent downstream apps from safely lowering syntax later.

Supporting older browsers

If your user base requires IE11 or older Safari versions:

pnpm add -D @vitejs/plugin-legacy

import { defineConfig } from "vite"
import legacy from "@vitejs/plugin-legacy"

export default defineConfig({
  plugins: [
    legacy({
      targets: ["defaults", "not IE 11"], // browserslist format
    }),
  ],
})

@vitejs/plugin-legacy will:

1. Build a modern ES Module version (for new browsers)
2. Also build a legacy SystemJS format (for old browsers)
3. Use <script type="module"> and <script nomodule> in HTML to distinguish between them

Verifying The Target

Target choice needs validation. Before release:

1. Run pnpm build and watch for syntax that cannot be transformed.
2. Open the production build in real target browsers or BrowserStack; do not trust only your local latest Chrome.
3. Inspect bundle reports and confirm legacy output does not blow up initial JS size.

If your support matrix is older than Baseline, write that requirement in the README or product technical constraints. Compatibility is a product decision, not something the bundler can solve alone.

Self-check

1. What is the difference between baseline-widely-available and es2022 as a target?
2. Why is Baseline more convenient than manually maintaining a browserslist?
3. If a project needs to support Safari on iOS 13, how should it be configured?
4. What does @vitejs/plugin-legacy do? How many sets of output does it produce?

// What build.target should be used for each scenario? Provide the configuration and your reasoning:

// Scenario A: A ToC utility app targeting developers on the latest Chrome
// Scenario B: A government information portal that needs to support IE 11
// Scenario C: An internal enterprise app where all users use company-issued Chrome 100
// Scenario D: A public marketing landing page that needs to reach as many users as possible

// For each scenario, write the recommended configuration:
import { defineConfig } from "vite"

// Scenario A:
const configA = defineConfig({
  build: { target: /* TODO */ }
})