Bundled dev mode design doc and Road Map

Bundled dev mode was previously called as "Full Bundle Mode".

Background and Motivation

Vite is known for its unbundled dev server approach, ...
However, as projects scale in size and complexity, two main challenges have emerged:

1. Development/Production inconsistency: ...
2. Performance degradation during development: ...

With the Rolldown integration, we have an opportunity to unify the development and production experiences while maintaining Vite's signature performance. A Full Bundle Mode would allow serving bundled files not only in production but also during development, combining the best of both worlds:

• Fast startup times even for large applications
• Consistent behavior between development and production
• Reduced network overhead on page refreshes
• Maintained efficient HMR on top of ESM output

Quoted from Rolldown Integration | Vite

User Guide

Q. As a user, can I use bundled dev mode now?
A. Only if your app does not use any SSR related features from Vite and the third party plugins are compatible. Third party plugins might be compatible, but we don't expect all to work. We'll be publishing plugin author guides in the future.

Q. How can I enable bundled dev mode?
A. You can enable it by experimental.bundledDev option or by passing --experimental-bundle flag.

Q. Does bundled dev mode bundle my entire app when the dev server starts?
A. No. Bundled dev mode uses lazy bundling (a.k.a. lazy compilation): on startup it only bundles what's needed to render the page the browser actually requests, and compiles the remaining modules on demand as they're imported. This is what keeps startup non-blocking even for large apps because bundling the whole app up front would reintroduce the slow cold starts that Vite's unbundled dev server was designed to avoid. It's enabled by default, so you don't need to configure anything.

Q. Can I disable lazy bundling?
A. You normally shouldn't need to, but it can be turned off. You can set build.rolldownOptions.experimental.devMode.lazy to opt out for debugging purposes:

import { defineConfig } from 'vite'

export default defineConfig({
  experimental: {
    bundledDev: true,
  },
  build: {
    rolldownOptions: {
      experimental: {
        devMode: {
          lazy: false,
        },
      },
    },
  },
})

Key Changes in Mental Models

Since bundled dev mode bundles the files, there will be some changes in the mental models.

• The served file structure would be different from the project files.
  • e.g. new URL("./foo.png", import.meta.url) should be rewritten to new URL("../relative-path/to/output/foo.png", import.meta.url)
  • Some of Vite's internal plugins utilize the fact that the file structure is preserved and skips the rewrite in development. But this won't be possible. Probably some of the frameworks / plugins that only runs in dev assume that.
• Importing a random file is not easily possible.
  • This is because the entrypoint files are only exposed from the files. Technically, we can re-generate the bundle when a non-entrypoint file is imported, but this is not implemented currently.
  • For SSR, this is how it is written in Vite docs (link). We have not considered how to make bundled dev mode work with SSR yet.
• Transforming a single module is not possible.
  • Technically, this is possible by exposing the functionality from Rolldown. But because the lifecycle of the plugins are different, it is difficult to expose without a big change.
• Output Generation Hooks are called for the initial bundle generation.
  • For file changes that can be applied by HMR, Vite generates a HMR patch file similar to unbundled mode. But for the patch files, the output generation hooks are not called.
• Dependency Optimizer does not run in bundled dev mode.

Roadmap

Work is sequenced as a series of experimental releases and is subject to frequent adjustment as things progress.

Checked items are complete; unchecked items are planned or in progress.

Phase 1: Basic CSR support

Goal: ship the first experimental release for Vite which is usable for client side rendering apps
Target date: 2026-06-22

• Option to opt-in to bundled dev
• Make the initial bundle generation work for all internal plugins: skipping non-needed ones
• Make the HMR patch file generation work for important internal plugins: updating the URL rewrite logics, watch files properly
• Serve the bundled files
• Lazy bundling implementation: [[Explain what]]
• Reliable HMR & module resolution
• Graceful error handling in dev

Phase 2: Complete CSR support

Goal: stabilize for real-world projects beyond the basic scenario. Land the HMR refactor that unblocks plugin support, get incremental rebuilds correct, and expand the support for advanced features like globs.
Target date: 2026-09-10

• Introduce input option (vite#22642): For full bundle mode, the entrypoint has to be specified. Currently, we use build.rollupOptions.input, but this is not intuitive for the users.
• Correct & efficient incremental rebuilds: [[Explain what]]
• HMR boundary calculation refactor: Currently the HMR calculation is done in the server. But it turned out that this has a problem. We plan to move the HMR calculation to the client. This blocks the plugin support.
• Investigate supporting hotUpdate / handleHotUpdate, or whether a different mechanism fits.
• HMR partial-accept support (experimental.hmrPartialAccept)
• Skip HMR / reload when the output doesn't change: Vite currently always triggers HMR / reload even when the output doesn't change. With bundled dev mode, this should be relatively easy to implement.
• Plugin / framework author guide: Held until the HMR refactor settles the plugin model, so authors only have to adapt once.
• Expose the watcher options on the Vite side
• Rebuild when tsconfig.json changes
• Proper import.meta.glob support: This requires watching directories, which does not have an API that can be used in plugins.
• Align transformIndexHtml in unbundled mode to full bundle mode / build (vite#20374)
• Fix the this.emitFile memory leak (See rollup#6095)
• Make the HMR patch file generation work for all internal plugins: updating the URL rewrite logics, watch files properly
• Make all playground in Vite repo work with bundled dev mode
• In Rolldown tests, track memory usage to guard against leaks
• Make FBM work on StackBlitz

Phase 3: CSS HMR & template coverage

Goal: deliver proper CSS HMR and validate FBM across all create-vite templates.
Target date: 2026-11-12

• Proper CSS HMR: Currently reuses Vite's existing CSS HMR approach.
• Framework & template coverage: Test all templates in create-vite

Phase 4: Server environments

Goal: extend full-bundle mode beyond SPAs to server / SSR environments.
Target date: unknown at this point

TBD

• initial PR: vite#21626
• API implications, from early notes (the concrete design may differ now that a prototype exists):
  • ViteDevServer.ssrLoadModule / env.runner.import: Since importing a random file is not easily possible, these APIs need to change (or Rolldown needs to improve that part). One option is to restrict them to entrypoint files. Another way is to generate the bundle on the fly.
  • ViteDevServer.pluginContainer / env.pluginContainer: difficult for the same reason as "Transforming a single module is not possible."
  • ViteDevServer.transformRequest / env.transformRequest: difficult for the same reason as "Transforming a single module is not possible."
  • ViteDevServer.moduleGraph / env.moduleGraph: a similar functionality is exposed from this.getModuleInfo; we can add the lacking functionality there.

High Level Explanation of how full bundle mode may work with the module runner

High Level Explanation of how full bundle mode may work with the module runner

1. Vite Dev Server generates bundled files and stores it in memory
2. Frameworks calls ViteDevServer.runner.dispatchFetch(entry)
3. The environment calls ModuleRunner.import(bundledFileEntry) on the remote runtime
4. The module runner asks the environment for the bundled file entry and executes it
5. A user changes a file
6. Vite Dev Server generates a HMR patch file for it and stores it in memory
7. The environment sends the HMR event to the remote runtime
8. The module runner asks for the HMR patch file and executes it

The difference is that the environment converts entry to bundledFileEntry.

Later

Deferred until after the HMR refactor; needs a feasibility pass (pros / cons / unknowns) before it's scheduled.

• One-pipeline model: fold the HMR/lazy codegen into the real build pipeline so asset URLs resolve chunk-independently, closing the HMR asset-resolution gap (404s on import x from './x.png' or new URL('./x', import.meta.url) inside patches). Expected to touch fewer plugins than the HMR refactor.
  • Trade-off: requires a dev-mode base / publicPath concept (today Vite-plugin-only); the lasting target is truly incremental HMR through the real render stage.

Plugin Compatibility Notes

Collapsed as it's not stable yet.

Details

• ViteDevServer.waitForRequestsIdle: this API does not work with full bundle mode and does not make sense with it
• Plugins that relied on the file structure being preserved need to rewrite the URLs for full bundle mode.
  • To achieve this, Vite forces the output chunks / assets to be put in a pre-defined structure so that the output URL / path can be calculated without actually generating the chunks/assets.
    • For example, all chunks are served below chunks/*.
    • Without this enforcement, the output URL will be unknown at transform hook and would require renderChunk hook which is not called for HMR patch files. Also, running renderChunk hooks of JS plugins are slow.
• Plugins now have to watch the files and register the dependencies properly.
  • In unbundled mode, refreshing the page always fetches the latest content. But in full bundle mode, the content is not updated unless the bundle is regenerated or a HMR patch file is generated. To trigger either of them, the plugin has to call this.addWatchFile to register the dependencies properly.
  • For some plugins, registering the dependencies is not possible (e.g. need to watch a directory like import.meta.glob requires). This will be tackled in the next phase.
• It is impossible to import a non-entry file from a file that is not included in the bundle. This can be solved by using a virtual module instead.

Current Status

Phase 1 (basic CSR support) is shipped. Work is now focused on Phase 2 (complete CSR support). Phase 4 (server environments) is on the PoC state.