[{"data":1,"prerenderedAt":4},["ShallowReactive",2],{"post-content-vite-8-rolldown-upgrade-what-actually-changed":3},"\u003Ch2>I Upgraded to Vite 8. The Builds Are Faster, But Not How You Think\u003C\u002Fh2>\n\n\u003Cp>I finally bit the bullet last weekend and upgraded a medium-sized Nuxt project from Vite 7 to Vite 8. I went in expecting the 10x speedup the blog posts promised. What I got was more nuanced and, honestly, more interesting.\u003C\u002Fp>\n\n\u003Cp>If you've been on the fence about upgrading, here's what actually changed, what broke, and whether it's worth your time.\u003C\u002Fp>\n\n\u003Ch3>The headline: Rolldown replaces two tools with one\u003C\u002Fh3>\n\n\u003Cp>Here's the short version. Before Vite 8, you had two bundlers in your pipeline without really thinking about it: esbuild handled dependency pre-bundling and transforms, and Rollup did the production build. Two tools, two plugin ecosystems, a bunch of glue code in between.\u003C\u002Fp>\n\n\u003Cp>Vite 8 replaces both with Rolldown — a single Rust-based bundler from the VoidZero team (the same people behind Oxc). It implements the Rollup plugin API, so most of your existing plugins should work. And because it's Rust, it's fast.\u003C\u002Fp>\n\n\u003Cp>How fast? Let me show you my numbers.\u003C\u002Fp>\n\n\u003Ch3>My benchmarks (not the marketing ones)\u003C\u002Fh3>\n\n\u003Cp>I ran builds three times each on the same machine, cold and warm, and averaged the results. This is a ~200-component Nuxt app with TypeScript, Vue SFCs, and a handful of plugins.\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Ctr>\n    \u003Cth>\u003C\u002Fth>\n    \u003Cth>Vite 7 (Rollup)\u003C\u002Fth>\n    \u003Cth>Vite 8 (Rolldown)\u003C\u002Fth>\n    \u003Cth>Change\u003C\u002Fth>\n  \u003C\u002Ftr>\n  \u003Ctr>\n    \u003Ctd>Production build (cold)\u003C\u002Ftd>\n    \u003Ctd>18.4s\u003C\u002Ftd>\n    \u003Ctd>3.1s\u003C\u002Ftd>\n    \u003Ctd>~6x faster\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n    \u003Ctd>Production build (warm)\u003C\u002Ftd>\n    \u003Ctd>17.9s\u003C\u002Ftd>\n    \u003Ctd>2.8s\u003C\u002Ftd>\n    \u003Ctd>~6.4x faster\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n    \u003Ctd>Dev server cold start\u003C\u002Ftd>\n    \u003Ctd>640ms\u003C\u002Ftd>\n    \u003Ctd>820ms\u003C\u002Ftd>\n    \u003Ctd>~28% slower\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n    \u003Ctd>HMR update (typical)\u003C\u002Ftd>\n    \u003Ctd>~30ms\u003C\u002Ftd>\n    \u003Ctd>~28ms\u003C\u002Ftd>\n    \u003Ctd>About the same\u003C\u002Ftd>\n  \u003C\u002Ftr>\n\u003C\u002Ftable>\n\n\u003Cp>Production builds are dramatically faster — no question about it. Six seconds down to three on a small project is noticeable. On larger codebases I've heard of 10-30x improvements, which tracks.\u003C\u002Fp>\n\n\u003Cp>But let's talk about the dev server. It's actually slower on a cold start. Not by a huge margin, and HMR feels identical in day-to-day use, but it's not the across-the-board win the headlines imply. The tradeoff is worth it for CI alone, but don't expect your local dev experience to transform overnight.\u003C\u002Fp>\n\n\u003Ch3>What broke during migration\u003C\u002Fh3>\n\n\u003Cp>I was ready for a fight. I cleared my schedule, poured a second coffee, and braced for plugin incompatibility hell.\u003C\u002Fp>\n\n\u003Cp>It was… mostly fine. Most plugins just worked.\u003C\u002Fp>\n\n\u003Cp>But I did hit three things:\u003C\u002Fp>\n\n\u003Cp>\u003Cstrong>1. A custom Rollup plugin that used \u003Ccode>this.error\u003C\u002Fcode> with a second argument.\u003C\u002Fstrong> Rolldown supports the Rollup API but not every single method signature variant. I had to change a \u003Ccode>this.error(msg, { id })\u003C\u002Fcode> call to attach the location differently. Minor, but it took 20 minutes to track down because the error message was cryptic.\u003C\u002Fp>\n\n\u003Cp>\u003Cstrong>2. \u003Ccode>vite-plugin-checker\u003C\u002Fcode> still works but adds overhead.\u003C\u002Fstrong> If you're using it for TypeScript checking, that's still a separate process and still takes most of the build time. My end-to-end build with type checking went from 24s to 11s — good, but the checker is now the bottleneck.\u003C\u002Fp>\n\n\u003Cp>\u003Cstrong>3. Some less common \u003Ccode>build.rollupOptions\u003C\u002Fcode> aren't fully implemented yet.\u003C\u002Fstrong> If you've got a heavily customized Rollup config with manualChunks that rely on specific module graph behavior, double-check the output. The bundle structure is similar but not byte-identical.\u003C\u002Fp>\n\n\u003Cp>The migration guide on the Vite site is solid — follow it, run your tests, and you'll probably be fine.\u003C\u002Fp>\n\n\u003Ch3>The feature nobody's talking about: full bundle mode\u003C\u002Fh3>\n\n\u003Cp>Here's the thing that actually got me excited, and I haven't seen many people mention it. With a single unified bundler, Vite can now do a \"full bundle\" in dev mode too — not just production.\u003C\u002Fp>\n\n\u003Cp>You enable it like this:\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode class=\"language-javascript\">\u002F\u002F vite.config.ts\nexport default defineConfig({\n  server: {\n    bundleMode: true\n  }\n})\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cp>Instead of transforming files on-demand as the browser requests them, Rolldown bundles everything upfront (but still fast, because Rust). For apps with hundreds of modules that cause a waterfall of requests on cold start, this can actually make the dev server feel snappier on first load, despite the slower startup time.\u003C\u002Fp>\n\n\u003Cp>It's not for every project — small apps probably won't notice. But if you've got a big monolith and you're tired of waiting for 300 module requests to trickle in, give it a shot.\u003C\u002Fp>\n\n\u003Ch3>Should you upgrade?\u003C\u002Fh3>\n\n\u003Cp>If you're on Vite 7 and your builds are starting to feel sluggish, yes. The production speedup alone pays for the 30 minutes of migration work. CI minutes get cheaper, deploy previews come back faster, and you get to delete a bunch of \"optimize the build\" tickets from your backlog.\u003C\u002Fp>\n\n\u003Cp>If you're on an older version, you'll want to go step by step (Vite 6 → 7 → 8) because there are other breaking changes between major versions. Don't try to jump three versions in one go.\u003C\u002Fp>\n\n\u003Cp>And if you're happy with your current setup and your builds are fast enough? No rush. The dev experience is basically the same. This is a build-time upgrade, not a developer-experience revolution.\u003C\u002Fp>\n\n\u003Cp>I keep my Vite config snippets, the migration checklist, the bundle mode toggle, and that weird plugin workaround, filed away in \u003Ca href=\"\u002Fsnippetark\u002F\">Snippet Ark\u003C\u002Fa> so I don't have to rediscover them next time I upgrade another project. The last thing you want during a dependency upgrade is to forget which config option fixed which problem.\u003C\u002Fp>\n",1787652455108]