Vite 31 ⚡ Bundled Dev Mode — Experimental full-bundle development for large apps
Vite’s unbundled dev server was the experiment that made it fast. For years, the pitch was simple: the browser requests modules on demand over native ESM, and the dev server transforms each file as it is requested. The approach worked because it avoided the upfront cost of bundling the entire application before the first page could load. But the experiment has a ceiling. Past a few thousand modules, the browser drowns in requests, and the startup time that was nearly instant for a small app becomes a visible delay for a large one. Bundled Dev Mode is the response: an opt-in mode that serves a Rolldown-bundled output during development, keeping the HMR mechanism but replacing the request waterfall with a small number of chunks .
The mode was previously called “Full Bundle Mode,” and it shipped as experimental in Vite 8.1. The metrics from the Vite team’s testing are specific: an app loading 10,000 React components saw roughly 15× faster startup and 10× faster full-page reloads compared to the unbundled dev server, while HMR remained instant regardless of application size . The Linear team’s real-world testing showed similar gains: cold start rendering up to 3× faster, full reloads around 40% faster, and 10× fewer network requests . The mode is experimental, and the documentation is clear that third-party plugins and minor features may not work with it yet .
Key point: Bundled Dev Mode is opt-in via --experimental-bundle or experimental.bundledDev: true. It serves a Rolldown-bundled output during development, which reduces the number of network requests for large applications. HMR is preserved, and the mode is browser-focused and experimental.
Why the unbundled model needed a bundled alternative
The request-count problem. Vite’s unbundled dev server serves every module as a separate request. A small application might make a few dozen requests. A large application with thousands of components makes thousands. The browser must request, parse, and execute each module, and the coordination overhead grows with the number of modules. The Vite team’s own description of the problem is direct: “as projects scale in size and complexity, it has become clear that Vite’s unbundled dev approach can degrade performance during development. Because each module is fetched separately, the browser must process a large number of requests, which increases startup and refresh overhead” . The problem is worse behind a network proxy, where each request pays an additional round-trip cost.
The Rolldown enabler. The reason the mode exists now, and not earlier, is Rolldown. The Vite team’s history page states it plainly: “Unbundled ESM was the right tradeoff when Vite was created because no tool was both fast enough and had the HMR and plugin capabilities needed to bundle during dev. Rolldown changes that” . Rolldown is the Rust-based bundler that replaced Rollup and esbuild in Vite 8, and its native speed makes the bundling step at dev-server startup acceptable. The bundled output is produced quickly enough that the startup gain from fewer requests outweighs the cost of the bundle .
The HMR preservation. The most important detail is that Bundled Dev Mode does not sacrifice HMR. The mode bundles the application at startup, but the hot updates continue to work through the same precise replacement mechanism. The Vite team’s announcement states that the mode keeps “efficient HMR on top of ESM output” . A developer who edits a component still sees only that component replaced, with the page state preserved. The bundling happens at startup and on full reload; the hot path is unchanged .
The trade-off. The mode is experimental, and the compatibility surface is narrower than the default. The announcement is explicit: “Currently, it focuses on the browser side and the basic plugins and the main features. If you are using a third party plugin, it may not work with this mode. If you are using a minor feature, it may not work as well” . A project that depends on a plugin ecosystem should test the mode on its own codebase before adopting it. The mode is also browser-focused; it does not cover the SSR or edge environments in the same way as the default dev server.
a. Enabling the mode and the configuration
The mode is enabled with a CLI flag or a configuration option. The CLI flag is --experimental-bundle. The configuration option is experimental.bundledDev: true in vite.config.ts.
// vite.config.ts — enabling Bundled Dev Mode
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
export default defineConfig({
plugins: [react()],
experimental: {
// The mode is experimental and opt-in.
// It serves a Rolldown-bundled output during development.
bundledDev: true,
},
});The CLI form is the same option without the config file change.
# Enable Bundled Dev Mode from the CLI
npx vite --experimental-bundleThe mode is a development-only feature. It is ignored for production builds, and it does not change the build output. The build command (vite build) continues to use the production pipeline, which is already bundled. The mode only changes how the dev server serves the application .
The documentation recommends testing the mode on a large application where the request count is the bottleneck. A small or medium project will see little benefit, because the unbundled server is already fast enough. The mode is for the case where the startup time and the full-page reload time have become visible costs, and the network request count is the cause .
b. The metrics and the compatibility boundary
The metrics from the Vite team’s testing are the starting point for evaluating the mode. The 10,000-component test is the synthetic benchmark, and the Linear production numbers are the real-world reference. The two sets are consistent: the synthetic test shows the upper bound of the improvement, and the production test shows the improvement on a real codebase.
| Scenario | Unbundled Dev | Bundled Dev Mode | Improvement |
|---|---|---|---|
| 10,000 React components startup | Baseline | ~15× faster | 15× |
| 10,000 React components full reload | Baseline | ~10× faster | 10× |
| Linear cold start rendering | Baseline | ~3× faster | 3× |
| Linear full reload | Baseline | ~40% faster | 1.67× |
| Linear first-screen network requests | Baseline | ~10× fewer | 90% reduction |
| HMR single component | ~50ms | ~50ms | Unchanged |
The table’s last row is the one that matters for the daily experience. The HMR speed is unchanged, which means the mode’s benefit is concentrated in the slow paths—the cold start and the full reload—and the fast path—the edit-and-see update—is not degraded .
The compatibility boundary is the other half of the evaluation. The mode’s current focus is the browser side, the basic plugins, and the main features. A project that uses a third-party plugin, or a minor feature that the mode does not cover, may see failures or missing behavior. The Vite team is expanding the support and preparing documentation for the plugin-side changes that may be needed . A project that adopts the mode should test the full feature set—the routing, the CSS handling, the asset imports, the plugin integrations—before relying on it for daily development.
Complete Example Session
// ============================================
// PART 1: THE CONFIGURATION
// ============================================
// vite.config.ts
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
export default defineConfig({
plugins: [react()],
experimental: {
// The mode is opt-in and experimental.
// It serves a bundled output during development.
bundledDev: true,
},
});
// ============================================
// PART 2: THE CLI ENABLEMENT
// ============================================
// npx vite --experimental-bundle
//
// The CLI flag enables the mode without the config change.
// The config change is the persistent form.
// ============================================
// PART 3: THE METRICS
// ============================================
// The Vite team's 10,000-component test:
// - Startup: ~15× faster
// - Full reload: ~10× faster
// - HMR: unchanged
//
// The Linear production test:
// - Cold start: ~3× faster
// - Full reload: ~40% faster
// - Network requests: ~10× fewer
//
// The production numbers are the realistic reference.
// ============================================
// PART 4: THE HMR BEHAVIOR
// ============================================
// The mode bundles at startup.
// The hot updates continue through the same HMR mechanism.
// A component edit replaces the component, not the page.
// The HMR speed is unchanged.
// ============================================
// PART 5: THE COMPATIBILITY TEST
// ============================================
// The mode focuses on the browser side and the basic plugins.
// A project should test:
// - The routing
// - The CSS handling
// - The asset imports
// - The plugin integrations
// - The HMR behavior
//
// A third-party plugin may not work with the mode.
// ============================================
// PART 6: THE RELATIONSHIP TO THE DEFAULT
// ============================================
// The mode is opt-in.
// The default unbundled server is unchanged.
// A project can switch back by removing the config option.
// ============================================
// PART 7: THE BUILD
// ============================================
// The mode is development-only.
// The build command (vite build) uses the production pipeline.
// The mode does not change the build output.
// ============================================
// PART 8: THE PROBLEM IT SOLVES
// ============================================
// The unbundled server serves each module as a request.
// A large app makes thousands of requests.
// The browser's request processing becomes the bottleneck.
// The mode serves a few bundled chunks instead.
// The request count drops.
// The startup and the full reload become faster.
// ============================================
// PART 9: THE LIMITATION
// ============================================
// The mode is experimental.
// The third-party plugins may not work.
// The minor features may not work.
// The documentation is still being prepared.
// The mode should be tested before adoption.
// ============================================
// PART 10: THE CHECKLIST
// ============================================
// [ ] The application is large enough that the request count is a bottleneck.
// [ ] The mode is enabled with the config option or the CLI flag.
// [ ] The startup time and the full reload time are measured.
// [ ] The HMR behavior is verified.
// [ ] The third-party plugins are tested.
// [ ] The asset imports and the CSS handling are verified.
// [ ] The mode is not used if the plugin compatibility is insufficient.The ten parts covered the configuration, the CLI enablement, the metrics, the HMR behavior, the compatibility test, the relationship to the default, the build, the problem, the limitation, and the checklist. The through-line is that the mode is a targeted fix for the request-count bottleneck in large applications, and it is opt-in because the compatibility surface is not yet universal.
Quick Reference
Enabling the mode
| Method | Syntax |
|---|---|
| Config | experimental: { bundledDev: true } |
| CLI | --experimental-bundle |
The metrics
| Scenario | Improvement |
|---|---|
| 10,000 components startup | ~15× |
| 10,000 components full reload | ~10× |
| Linear cold start | ~3× |
| Linear full reload | ~40% |
| Linear network requests | ~10× fewer |
| HMR speed | Unchanged |
The compatibility scope
| Aspect | Status |
|---|---|
| Browser side | Supported |
| Basic plugins | Supported |
| Main features | Supported |
| Third-party plugins | May not work |
| Minor features | May not work |
| SSR/edge environments | Not the focus |
Best Practices
✅ Do This:
// Enable the mode for a large application
experimental: { bundledDev: true } // ✅
// Test the full feature set before adopting
// Routing, CSS, assets, plugins, HMR // ✅
// Measure the startup and reload times
// The metrics are the reason to adopt // ✅❌ Don’t Do This:
// Enable the mode for a small application
// The unbundled server is already fast. // ❌
// Assume all third-party plugins work
// The mode's compatibility surface is narrower. // ❌
// Expect the mode to change the production build
// It is a dev-only feature. // ❌Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| A plugin fails | The mode’s compatibility surface is narrower | Test the plugin or disable the mode |
| The HMR is slower | The mode is not the cause; the HMR is unchanged | Check the plugin or the configuration |
| The mode has no effect | The application is too small for the request count to matter | Use the default server |
| The production build changes | The mode is dev-only | The build is unchanged |
Real-World Examples
1. The config
experimental: { bundledDev: true }2. The CLI
npx vite --experimental-bundle3. The startup metric
10,000 components: ~15× faster4. The reload metric
10,000 components: ~10× faster5. The production metric
Linear cold start: ~3× faster6. The network metric
Linear: ~10× fewer requests7. The HMR
Unchanged8. The compatibility test
// Test the plugins, the CSS, the assets9. The build
vite build # unchanged10. The opt-in
// Remove the config to return to the defaultVisual
The Request Count Problem
┌──────────────────────────────────────────────────────────────┐
│ UNBUNDLED VS BUNDLED DEV │
│ │
│ Unbundled Bundled │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ Browser requests │ │ Browser requests │ │
│ │ each module │ │ a few chunks │ │
│ │ │ │ │ │
│ │ 1000s of requests │ │ ~10s of requests │ │
│ │ High overhead │ │ Low overhead │ │
│ └─────────────────────┘ └─────────────────────┘ │
│ │
│ The bundled mode reduces the request count. │
│ The startup and the full reload become faster. │
└──────────────────────────────────────────────────────────────┘The HMR Preservation
┌──────────────────────────────────────────────────────────────┐
│ HMR IS UNCHANGED │
│ │
│ Bundled mode startup: bundle the app │
│ │ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ The app is served │ │
│ │ as a few chunks │ │
│ └──────────┬──────────┘ │
│ │ │
│ ▼ │
│ Developer edits a component │
│ │ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ HMR replaces the │ The same precise replacement │
│ │ component │ The page state is preserved │
│ └─────────────────────┘ │
└──────────────────────────────────────────────────────────────┘The Compatibility Boundary
┌──────────────────────────────────────────────────────────────┐
│ WHAT THE MODE COVERS │
│ │
│ ✅ Browser side │
│ ✅ Basic plugins │
│ ✅ Main features │
│ │
│ ❌ Third-party plugins (may not work) │
│ ❌ Minor features (may not work) │
│ ❌ SSR/edge environments (not the focus) │
└──────────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| Name | Bundled Dev Mode (formerly Full Bundle Mode) |
| Status | Experimental, Vite 8.1 |
| Enable | experimental.bundledDev: true or --experimental-bundle |
| 10,000-component startup | ~15× faster |
| 10,000-component full reload | ~10× faster |
| Linear cold start | ~3× faster |
| Linear network requests | ~10× fewer |
| HMR | Unchanged |
| Compatibility | Browser side, basic plugins, main features |
Key takeaways:
- Bundled Dev Mode targets the request-count bottleneck. The unbundled dev server serves each module as a separate request, and a large application makes thousands. The mode serves a Rolldown-bundled output instead, which reduces the request count and speeds up the startup and the full reload .
- The mode preserves HMR. The bundling happens at startup and on full reload. The hot updates continue through the same precise replacement mechanism, and the HMR speed is unchanged .
- The metrics are specific and bounded. The 10,000-component test shows ~15× startup and ~10× full reload. The Linear production test shows ~3× cold start, ~40% faster reloads, and ~10× fewer requests. The production numbers are the realistic reference .
- The mode is opt-in and experimental. The compatibility surface is narrower than the default. Third-party plugins and minor features may not work. The Vite team is expanding the support and preparing the plugin documentation .
- The mode is dev-only. The production build is unchanged. The mode only changes how the dev server serves the application. A project can switch back by removing the config option .
Remember: Bundled Dev Mode is the answer to the request-count problem that the unbundled dev server creates for large applications. It bundles the application at startup with Rolldown, serves a small number of chunks, and keeps the HMR mechanism unchanged. The mode is opt-in because the compatibility surface is not yet universal, and the metrics are the reason to adopt it: a large application’s startup and full reload become faster, while the daily edit-and-see experience remains the same.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!