Full Bundle Mode (Experimental)

Limitations of native ESM dev

Vite's dev server uses native ESM by default: each module is requested individually. This enables extremely fast cold starts, but comes with a cost:

Problem 1: High number of HTTP requests

Large projects can have thousands of modules. Browsers have a limited number of concurrent connections (HTTP/2 is not unlimited either), so the first load can have noticeable latency.

Problem 2: Dev/build behavior differences

Even though Rolldown unifies the transform pipeline, the dev mode still doesn't bundle — no tree-shaking, no chunk splitting. Some problems that only appear after bundling are invisible during development.

Problem 3: Cannot simulate CDN scenarios

Some third-party libraries behave differently as CDN builds versus npm packages. Native ESM dev cannot simulate these scenarios.

The Full Bundle Mode approach

Full Bundle Mode makes the dev server produce a complete bundle too:

Current dev mode:
  Browser requests /src/App.tsx
    → Vite transform (single file)
    → Returns a single ESM module
    → Browser requests dependencies...
  (dozens to thousands of requests)

Full Bundle Mode:
  Vite builds a dev bundle with Rolldown
    → All modules bundled (but not minified)
    → HMR still supported (incremental bundle)
    → Only 1 to a few requests

Trade-offs

Best suited for: high-latency network environments, scenarios that require precise simulation of production behavior.

How To Track This Direction

Do not invent configuration fields in documentation. Full Bundle Mode related work should be tracked through official Vite docs, GitHub issues, and release notes. A practical workflow today:

1. Read Vite GitHub issues related to bundled dev and the Rolldown dev server.
2. Use @vitejs/devtools or build logs to inspect request counts and transform hotspots in large projects.
3. First optimize dependency pre-bundling, HMR boundaries, and initial route requests under the current ESM dev model.
4. Adopt the feature only after the official API stabilizes.

Decide Whether It Is Worth Waiting For

Full Bundle Mode is not automatically better. If your bottleneck is a slow transform plugin, full bundling still has to run that transform. If your bottleneck is too many browser requests, it is more likely to help.

What To Optimize Today

Before the official API stabilizes, projects with "too many modules and slow first load" can use proven optimizations first:

1. Use 12.1 · Cold Start Optimization to fix dependency pre-bundling and second reloads.
2. Use 7.4 · Code Splitting to delay large features until users enter the route.
3. Use 12.3 · HMR Performance Diagnostics to find oversized propagation chains.
4. Use @vitejs/devtools to inspect the module graph and transform hotspots before assuming request count is the bottleneck.

These optimizations do not depend on experimental config, and they remain valuable even if Full Bundle Mode stabilizes later.

Self-check

1. Why does native ESM dev mode produce a large number of HTTP requests?
2. What does Full Bundle Mode give up in exchange for what?
3. What types of projects would benefit most from Full Bundle Mode?
4. How does HMR work under Full Bundle Mode?

// Thought exercise:
// If your project has 2,000 modules,
// using native ESM dev might take 3–5 seconds on first load (on a slow network)
// using Full Bundle Mode might take 5 seconds to cold start, but first load is fast
//
// For each of the following development scenarios, which mode would you choose? Explain your reasoning:
// A: Local development, SSD, Chrome
// B: Developing via SSH remote connection to a server
// C: Running integration tests in CI
// D: Showing results to a designer (their network may be slow)