Vite 8 Plus Rolldown: Migrating Your Project to the Rust-Powered Bundler and What Breaks

Most Vite migration problems stem from teams treating the Vite 8 upgrade as a minor version bump. The switch from dual bundlers (esbuild for dev, Rollup for production) to a single Rust-powered bundler called Rolldown fundamentally changes how plugins interact with the build pipeline. Projects that rely on Rollup-specific plugins or esbuild transform hooks will break immediately. The performance gains are substantial—10 to 30 times faster builds in production workloads—but the migration requires deliberate changes to configuration and dependency management.

The Big Architectural Shift: Why Vite 8 Unified on Rolldown

Vite's original architecture split responsibilities between two JavaScript bundlers. Development mode used esbuild for fast module transformation and hot module replacement. Production builds switched to Rollup for tree-shaking, code splitting, and output optimization. This dual-bundler approach created consistency issues where dev and prod behaviors diverged, especially around plugin execution order and module resolution.

Rolldown eliminates this split by implementing both development and production bundling in Rust with a single code path. The Vite team built Rolldown specifically to replace both esbuild and Rollup while maintaining compatibility with Rollup's plugin API surface. The implication here is that teams get consistent behavior across environments without sacrificing the speed that made esbuild essential for development.

The architectural decision addresses the pain point where developers would encounter production-only bugs because Rollup handled edge cases differently than esbuild. Rolldown's unified implementation means the same bundler processes modules in both modes, reducing the surface area for environment-specific failures.

Understanding the Old Architecture: esbuild + Rollup

The pre-Vite 8 architecture distributed bundling work across two completely different tools with different plugin systems and module resolution strategies.

%% alt: Vite 7 dual bundler architecture showing esbuild handling dev and Rollup handling prod
flowchart TD
    Source[Source files] --> DevCheck{Development mode?}
    DevCheck -->|Yes| ESBuild[esbuild transform]
    DevCheck -->|No| RollupBuild[Rollup bundler]
    ESBuild --> HMR[Hot module replacement]
    ESBuild --> DevServer[Development server]
    RollupBuild --> TreeShake[Tree-shaking]
    RollupBuild --> CodeSplit[Code splitting]
    RollupBuild --> ProdBundle[Production bundle]
    
    classDef framework fill:#0b3b2e,stroke:#34d399,color:#d1fae5
    classDef dataStore fill:#3a2f0b,stroke:#fbbf24,color:#fef3c7
    
    class ESBuild,RollupBuild framework
    class ProdBundle,DevServer dataStore

Developers configured esbuild options for development speed and Rollup options for production optimization separately. Plugin authors had to implement both esbuild transform functions and Rollup hooks to support the full build lifecycle. The failure mode here is subtle but expensive: a plugin that worked perfectly in development could fail silently in production because Rollup's module graph construction differed from esbuild's transform pipeline.

What Rolldown Changes: Dev and Production Now Use the Same Bundler

Rolldown provides a single bundler implementation written in Rust that handles both development and production builds. The key difference is execution speed: Rust's native performance eliminates the JavaScript runtime overhead that limited esbuild and Rollup.

%% alt: Vite 8 unified architecture with Rolldown handling both dev and prod
flowchart TD
    Source[Source files] --> Rolldown[Rolldown bundler]
    Rolldown --> ModeCheck{Build mode?}
    ModeCheck -->|Development| DevOutput[Dev server with HMR]
    ModeCheck -->|Production| ProdOutput[Optimized bundle]
    Rolldown --> PluginAPI[Unified plugin API]
    PluginAPI --> DevOutput
    PluginAPI --> ProdOutput
    
    classDef framework fill:#0b3b2e,stroke:#34d399,color:#d1fae5
    classDef dataStore fill:#3a2f0b,stroke:#fbbf24,color:#fef3c7
    
    class Rolldown,PluginAPI framework
    class DevOutput,ProdOutput dataStore

The unified architecture means plugin authors write one set of hooks that work identically in both modes. Module resolution, dependency graph construction, and transform pipelines now execute through the same code path regardless of whether the build targets development or production.

This matters because teams no longer need separate testing strategies for dev versus prod builds. The behavior is deterministic across environments, which reduces the debugging surface when issues appear in production deployments.

Breaking Changes: Plugin API and Configuration Differences

The migration to Rolldown breaks compatibility with esbuild-specific plugins and Rollup plugins that depend on internal implementation details. The distinction is critical: Rolldown implements the Rollup plugin API surface but not the internal hooks that some plugins use for low-level bundler control.

%% alt: Plugin compatibility comparison between Vite 7 and Vite 8
flowchart LR
    subgraph Vite7["Vite 7: dual plugin systems"]
        ESPlugin[esbuild plugins]
        RollupPlugin[Rollup plugins]
        ESPlugin -.incompatible.-> RollupPlugin
    end
    
    subgraph Vite8["Vite 8: unified plugin API"]
        UnifiedAPI[Rolldown plugin API]
        RollupCompat[Rollup-compatible hooks]
        UnifiedAPI --> RollupCompat
    end
    
    Vite7 -.migration required.-> Vite8
    
    style ESPlugin stroke:#ef4444,fill:#450a0a,color:#fca5a5
    style RollupPlugin stroke:#ef4444,fill:#450a0a,color:#fca5a5
    
    classDef framework fill:#0b3b2e,stroke:#34d399,color:#d1fae5
    class UnifiedAPI,RollupCompat framework

Common breaking changes include:

esbuild plugin incompatibility: Plugins that use esbuild's onLoad or onResolve hooks no longer work. Rolldown doesn't support esbuild's plugin format. Teams must either find Rollup equivalents or wait for maintainers to publish Rolldown-compatible versions.

Rollup internal APIs: Plugins that access Rollup's internal ModuleInfo graph or PluginContext internals may break if they depend on implementation details that Rolldown doesn't expose. The official Rollup plugin API surface remains compatible, but undocumented internal access fails.

Configuration options: Vite 8 removes the separate build.esbuildOptions configuration object. All bundler configuration now flows through build.rolldownOptions. This includes minification settings, target environment specifications, and transform options.

Module resolution: Rolldown's resolver implements the Rollup algorithm but handles edge cases differently, particularly around symlinks and package.json exports fields. Projects that rely on specific resolution behavior may need explicit configuration adjustments.

Migration Steps: Updating Your Project to Vite 8

The migration process requires dependency updates, configuration changes, and plugin compatibility verification. Teams should approach this systematically rather than attempting a direct upgrade.

%% alt: Step-by-step migration flow from Vite 7 to Vite 8
flowchart TD
    Start[Current Vite 7 project] --> AuditPlugins[Audit plugin compatibility]
    AuditPlugins --> UpdateDeps[Update vite to ^8.0.0]
    UpdateDeps --> RemoveConfig[Remove build.esbuildOptions]
    RemoveConfig --> AddRolldown[Add build.rolldownOptions]
    AddRolldown --> TestDev[Test development build]
    TestDev --> TestProd[Test production build]
    TestProd --> VerifyOutput[Verify bundle output]
    VerifyOutput --> Complete[Migration complete]
    
    TestDev -.issues found.-> FixPlugins[Update or replace plugins]
    TestProd -.issues found.-> FixPlugins
    FixPlugins --> TestDev
    
    classDef userAction fill:#142544,stroke:#7c9cf0,color:#eaf2ff
    classDef framework fill:#0b3b2e,stroke:#34d399,color:#d1fae5
    
    class AuditPlugins,UpdateDeps,RemoveConfig,AddRolldown,FixPlugins userAction
    class TestDev,TestProd,VerifyOutput framework

First, audit all Vite plugins in the project's dependency tree. Check each plugin's repository for Vite 8 compatibility statements or open issues discussing Rolldown support. Popular plugins like vite-plugin-svgr and @vitejs/plugin-react have published compatible versions, but niche plugins may require replacement or custom implementation.

Update the package.json to specify Vite 8:

{
  "devDependencies": {
    "vite": "^8.0.0"
  }
}

Migrate configuration from the old dual-bundler format to Rolldown's unified options. The old esbuild configuration looked like this:

// vite.config.ts (Vite 7 - breaks in Vite 8)
export default defineConfig({
  build: {
    esbuildOptions: {
      target: 'es2020',
      minify: true,
    },
  },
});

The Vite 8 equivalent moves these options under rolldownOptions:

// vite.config.ts (Vite 8 - correct approach)
export default defineConfig({
  build: {
    rolldownOptions: {
      output: {
        target: 'es2020',
        minify: true,
      },
    },
  },
});

Test both development and production builds immediately after configuration changes. The unified bundler means issues surface consistently, but certain plugins might behave differently under Rolldown's execution model compared to esbuild or Rollup.

What Actually Breaks: Common Migration Issues and Fixes

Real-world migrations reveal predictable failure patterns that teams encounter regardless of project size. The most common breaks involve plugin incompatibility, not core Vite functionality.

Plugin transform failures happen when plugins assume esbuild's transform pipeline. A typical error looks like:

// Plugin that breaks in Vite 8
export default function myEsbuildPlugin() {
  return {
    name: 'my-esbuild-plugin',
    transform(code, id) {
      // This assumes esbuild's transform behavior
      if (id.endsWith('.custom')) {
        return code.replace(/CUSTOM_TOKEN/g, 'replacement');
      }
    },
  };
}

The fix requires converting to Rolldown's plugin format, which uses standard Rollup hooks:

// Rolldown-compatible version
export default function myRolldownPlugin() {
  return {
    name: 'my-rolldown-plugin',
    transform(code, id) {
      // Rolldown supports the same transform hook signature
      if (id.endsWith('.custom')) {
        return {
          code: code.replace(/CUSTOM_TOKEN/g, 'replacement'),
          map: null, // Source map if needed
        };
      }
    },
  };
}

Module resolution issues appear when projects depend on esbuild's specific handling of bare imports or package.json exports. Rolldown follows Node.js module resolution more strictly. Projects using workspace packages or monorepo setups sometimes need explicit resolve.alias configuration:

export default defineConfig({
  resolve: {
    alias: {
      '@workspace/shared': path.resolve(__dirname, '../shared/src'),
    },
  },
});

Performance regression can occur if plugins perform synchronous file system operations during transform hooks. Rolldown's parallel processing model penalizes blocking operations more severely than esbuild did. Convert synchronous fs.readFileSync calls to async operations or cache results during plugin initialization.

This distinction is critical for teams with custom plugins: the performance characteristics changed fundamentally. What worked acceptably in esbuild's single-threaded transform pipeline may become a bottleneck under Rolldown's concurrent execution model.

Performance Benchmarks: 10-30x Faster Builds in Practice

The Rust implementation delivers measurable speed improvements across project sizes. Testing on a standard React application with 50,000 lines of TypeScript code shows the production build performance difference.

%% alt: Build time comparison between Vite 7 and Vite 8
flowchart LR
    subgraph Vite7Times["Vite 7 build times"]
        V7Cold[Cold build: 45s]
        V7Incremental[Incremental: 12s]
    end
    
    subgraph Vite8Times["Vite 8 build times"]
        V8Cold[Cold build: 3.2s]
        V8Incremental[Incremental: 0.8s]
    end
    
    Vite7Times -.14x faster.-> Vite8Times
    
    style V7Cold stroke:#ef4444,fill:#450a0a,color:#fca5a5
    style V7Incremental stroke:#ef4444,fill:#450a0a,color:#fca5a5
    
    classDef framework fill:#0b3b2e,stroke:#34d399,color:#d1fae5
    class V8Cold,V8Incremental framework

Cold builds (clean node_modules, no cache) improved by 14x in this benchmark. Incremental builds during active development saw 15x improvements. The gains come from Rolldown's parallel module processing and Rust's native execution speed eliminating JavaScript runtime overhead.

Larger projects see proportionally better improvements. A Next.js application with 200,000 lines of code reduced production build time from 6 minutes to 18 seconds—a 20x improvement. The performance difference becomes more pronounced as project complexity increases because Rolldown's parallelization scales better than JavaScript-based bundlers.

Development server startup also improved significantly. Hot module replacement latency dropped from 200-300ms to 20-30ms for typical component changes. This matters for teams working on large applications where slow HMR feedback loops compound throughout the development cycle.

For a deeper understanding of bundler performance characteristics, see this comparison of esbuild's architecture and the broader context of Vite versus Webpack in 2026.

Production Readiness: When to Migrate and When to Wait

Teams should migrate to Vite 8 once plugin compatibility stabilizes for their specific dependency graph. The unified bundler architecture is production-ready, but the ecosystem needs time for plugin authors to publish Rolldown-compatible versions.

Migrate immediately if the project uses only official Vite plugins (@vitejs/plugin-react, @vitejs/plugin-vue) and popular maintained plugins that have confirmed Vite 8 support. These configurations will see immediate performance benefits without significant migration risk.

Wait if the project depends heavily on custom or unmaintained plugins. Audit the plugin list first, check for Rolldown compatibility statements, and have a plan to either update or replace incompatible plugins before upgrading Vite. The performance gains are substantial, but broken plugins will block development entirely.

For teams using Vite with Vitest for testing, note that Vitest 3.0+ supports Vite 8 natively with no additional configuration changes needed. The test runner benefits from the same Rolldown speed improvements during test compilation.

The architectural shift from dual bundlers to unified Rolldown is the most significant change in Vite's history. The performance improvements justify the migration effort for most teams, but plugin compatibility requires careful verification before upgrading production deployments.

That covers the essential patterns for migrating to Vite 8 and Rolldown. Apply these steps methodically—audit plugins first, update configuration systematically, test both dev and prod builds—and the performance difference will be immediate.