Vite 8 Release Announcement
March 12, 2026
We're thrilled to announce the stable release of Vite 8! When Vite first launched, we made a pragmatic bet on two bundlers: esbuild for speed during development, and Rollup for optimized production builds. That bet served us well for years. We're very grateful to the Rollup and esbuild maintainers. Vite wouldn't have succeeded without them. Today, it resolves into one: Vite 8 ships with Rolldown as its single, unified, Rust-based bundler, delivering up to 10-30x faster builds while maintaining full plugin compatibility. This is the most significant architectural change since Vite 2.
Vite is now being downloaded 65 million times a week, and the ecosystem continues to grow with every release. To help developers navigate the ever-expanding plugin landscape, we also launched registry.vite.dev, a searchable directory of plugins for Vite, Rolldown, and Rollup that collects plugin data from npm daily.
Quick links:
Play online with Vite 8 using vite.new or scaffold a Vite app locally with your preferred framework running pnpm create vite. Check out the Getting Started Guide for more information.
We invite you to help us improve Vite (joining the more than 1.2K contributors to Vite Core), our dependencies, or plugins and projects in the ecosystem. Learn more at our Contributing Guide. A good way to get started is by triaging issues, reviewing PRs, sending tests PRs based on open issues, and supporting others in Discussions or Vite Land's help forum. If you have questions, join our Discord community and talk to us in the #contributing channel.
Stay updated and connect with others building on top of Vite by following us on Bluesky, X, or Mastodon.
The Rolldown-Powered Vite
The problem
Since its earliest versions, Vite relied on two separate bundlers to serve different needs. esbuild handled fast compilation during development (dependency pre-bundling and TypeScript/JSX transforms) that made the dev experience feel instant. Rollup handled production bundling, chunking, and optimization, with its rich plugin API powering the entire Vite plugin ecosystem.
This dual-bundler approach served Vite well for years. It allowed us to focus on developer experience and orchestration rather than reinventing parsing and bundling from scratch. But it came with trade-offs. Two separate transformation pipelines meant two separate plugin systems, and an increasing amount of glue code needed to keep the two pipelines in sync. Edge cases around inconsistent module handling accumulated over time, and every alignment fix in one pipeline risked introducing differences in the other.
The solution
Rolldown is a Rust-based bundler built by the VoidZero team to address these challenges head-on. It was designed with three goals:
- Performance: Written in Rust, Rolldown operates at native speed. In benchmarks, it is 10-30x faster than Rollup matching esbuild's performance level.
- Compatibility: Rolldown supports the same plugin API as Rollup and Vite. Most existing Vite plugins work out of the box with Vite 8.
- Advanced features: A single unified bundler unlocks capabilities that were difficult or impossible with the dual-bundler setup, including full bundle mode, more flexible chunk splitting, module-level persistent caching, and Module Federation support.
The journey to stable
The migration to Rolldown was deliberate and community-driven. First, a separate rolldown-vite package was released as a technical preview, allowing early adopters to test Rolldown's integration without affecting the stable version of Vite. The feedback from those early adopters was invaluable. They pushed the integration through real-world codebases of every shape and size, surfacing edge cases and compatibility issues we could address before a wider release. We also set up a dedicated CI suite validating key Vite plugins and frameworks against the new bundler, catching regressions early and building confidence in the migration path.
In December 2025, we shipped the Vite 8 beta with Rolldown fully integrated. During the beta period, Rolldown itself progressed from beta to a release candidate, with continuous improvements driven by the testing and feedback of the Vite community.
Real-world performance
During the preview and beta phases of rolldown-vite, several companies reported measurable reductions in production build times:
- Linear: Production build times dropped from 46s to 6s
- Ramp: 57% build time reduction
- Mercedes-Benz.io: Up to 38% build time reduction
- Beehiiv: 64% build time reduction
For large projects, the impact can be especially noticeable, and we expect further improvements as Rolldown continues to evolve.
A unified toolchain
With Vite 8, Vite becomes the entry point to an end-to-end toolchain with closely collaborating teams: the build tool (Vite), the bundler (Rolldown), and the compiler (Oxc). This alignment ensures consistent behavior across the entire stack, from parsing and resolving to transforming and minifying. It also means we can rapidly adopt new language specifications as JavaScript evolves. And by integrating deeply across layers, we can pursue optimizations that were previously out of reach, such as leveraging Oxc's semantic analysis for better tree-shaking in Rolldown.
Thank you to the community
None of this would have been possible without the broader community. We want to extend our deep thanks to the framework teams (SvelteKit, React Router, Storybook, Astro, Nuxt, and many others) who tested rolldown-vite early, filed detailed bug reports, and worked with us to resolve compatibility issues. We are equally grateful to every developer who tried the beta, shared their build time improvements, and reported the rough edges that helped us polish this release. Your willingness to test the migration on real projects helped make the transition to Rolldown smoother and more reliable.
Node.js Support
Vite 8 requires Node.js 20.19+, 22.12+, the same requirements as Vite 7. These ranges ensure Node.js supports require(esm) without a flag, allowing Vite to be distributed as ESM only.
Additional Features
Beyond the Rolldown integration, Vite 8 includes several notable features:
Integrated Devtools: Vite 8 ships
devtoolsoption to enable Vite Devtools, a developer tooling for debugging and analysis. Vite Devtools provide deeper insights into your Vite-powered projects directly from the dev server.Built-in tsconfig
pathssupport: Developers can enable TypeScript path alias resolution by settingresolve.tsconfigPathstotrue. This has a small performance cost and is not enabled by default.emitDecoratorMetadatasupport: Vite 8 now has built-in automatic support for TypeScript'semitDecoratorMetadataoption, removing the need for external plugins. See the Features page for details.Wasm SSR support:
.wasm?initimports now work in SSR environments, expanding Vite's WebAssembly feature to server-side rendering.Browser console forwarding: Vite 8 can forward browser console logs and errors to the dev server terminal. This is especially useful when working with coding agents, as runtime client errors become visible in the CLI output. Enable it with
server.forwardConsole, which activates automatically when a coding agent is detected.
@vitejs/plugin-react v6
Alongside Vite 8, we are releasing @vitejs/plugin-react v6. The plugin uses Oxc for React Refresh transform. Babel is no longer a dependency and the installation size is smaller.
For projects that need the React Compiler, v6 provides a reactCompilerPreset helper that works with @rolldown/plugin-babel, giving you an explicit opt-in path without burdening the default setup.
See the Release Notes for more details.
Note that v5 still works with Vite 8, so you can upgrade the plugin after upgrading Vite.
The Rolldown integration opens the door to improvements and optimizations. Here is what we are working on next:
Full Bundle Mode (experimental): This mode bundles modules during development, similar to production builds. Preliminary results show 3x faster dev server startup, 40% faster full reloads, and 10x fewer network requests. This is especially impactful for large projects where the unbundled dev approach hits scaling limits.
Raw AST transfer: Allows JavaScript plugins to access the Rust-produced AST with minimal serialization overhead, bridging the performance gap between Rust internals and JS plugin code.
Native MagicString transforms: Enables custom transforms where the logic lives in JavaScript but the string manipulation computation runs in Rust.
Stabilizing the Environment API: We are working to make the Environment API stable. The ecosystem has started regular meetings to better collaborate together.
Install Size
We want to be transparent about changes to Vite's install size. Vite 8 is approximately 15 MB larger than Vite 7 on its own. This comes from two main sources:
- ~10 MB from lightningcss: Previously an optional peer dependency, lightningcss is now a normal dependency to provide better CSS minification out of the box.
- ~5 MB from Rolldown: The Rolldown binary is larger than esbuild + Rollup mainly due to performance optimizations that favor speed over binary size.
We will continue monitoring and working to reduce install size as Rolldown matures.
Migrating to Vite 8
For most projects, upgrading to Vite 8 should be a smooth process. We built a compatibility layer that auto-converts existing esbuild and rollupOptions configuration to their Rolldown and Oxc equivalents, so many projects will work without any config changes.
For larger or more complex projects, we recommend the gradual migration path: first switch from vite to the rolldown-vite package on Vite 7 to isolate any Rolldown-specific issues, then upgrade to Vite 8. This two-step approach makes it easy to identify whether any issues come from the bundler change or from other Vite 8 changes.
Please review the detailed Migration Guide before upgrading. The complete list of changes is in the Vite 8 Changelog.
Thank You, Rollup and esbuild
As Vite moves to Rolldown, we want to take a moment to express our deep gratitude to the two projects that made Vite possible.
Rollup has been Vite's production bundler since the very beginning. Its elegant plugin API design proved so well-conceived that Rolldown adopted it as its own, and Vite's entire plugin ecosystem exists because of the foundation Rollup laid. The quality and thoughtfulness of Rollup's architecture shaped how Vite thinks about extensibility. Thank you, Rich Harris for creating Rollup, and Lukas Taegert-Atkinson and the Rollup team for maintaining and evolving it into something that has had such a lasting impact on the web tooling ecosystem.
esbuild powered Vite's remarkably fast development experience from its early days: dependency pre-bundling, TypeScript and JSX transforms that completed in milliseconds rather than hundreds. esbuild proved that build tools could be orders of magnitude faster, and its speed set the bar that inspired an entire generation of Rust and Go-based tooling. Thank you, Evan Wallace, for showing all of us what was possible.
Without these two projects, Vite would not exist as it does today. Even as we move forward with Rolldown, the influence of Rollup and esbuild is deeply embedded in Vite's DNA, and we are grateful for everything they have given to the ecosystem. You can learn more about all the projects and people Vite depends on at our Acknowledgements page.
Acknowledgments
Vite 8 was led by sapphi-red and the Vite Team with the help of the wide community of contributors, downstream maintainers, and plugin authors. We want to thank the Rolldown team for their close collaboration in making the Rolldown-powered Vite 8 possible. We are also especially grateful to everyone who participated in the rolldown-vite preview and the Vite 8 beta period. Your testing, bug reports, and feedback made the Rolldown migration possible and shaped this release into something we are proud of.
Vite is brought to you by VoidZero, in partnership with Bolt and NuxtLabs. We also want to thank our sponsors on Vite's GitHub Sponsors and Vite's Open Collective.
Read the original article
Comments
By upsuper 2026-03-1315:36 I contributed this change in Vite 8:
> Wasm SSR support: .wasm?init imports now work in SSR environments, expanding Vite's WebAssembly feature to server-side rendering.
While the process was relatively slow, I really appreciate the extra effort that the team have put on even this minor feature add. They not only guided me towards more compatible and idiomatic approach, but also added docs and helped keeping the code up to date before merging.
Yeah, it makes you wonder how much computing power the industry has wasted over the years on tools that nobody questioned because "that's just how long builds take." We planned our work around it, joked about creating breaks, and built entire caching layers to work around it.
Kudos to the Vite maintainers!
By semiquaver 2026-03-1313:582 reply The waste of slow JS bundles is nothing compared to the cost of bloated interpreted runtimes or inefficient abstractions. Most production software is multiple orders of magnitude slower than it needs to be. Just look at all the electron apps that use multiple GB of ram doing nothing and are laggier than similar software written 40 years ago despite having access to an incredibly luxurious amount of resources from any sane historical perspective.
By shimman 2026-03-1314:28 Something I realized while doing more political campaign work is how inefficient most self hosted solutions are. Things like plausible or umami (analytics) require at least 2 gigs of ram, postiz (scheduled social media planner) requires 2 gigs of ram, etc.
It all slowly adds up where you think a simple $10 VPS with 2 gigs of ram is enough but it's not, especially if you want a team of 10-30ish to work sporadically within the same box.
There can be a lot of major wins by rewriting these programs in more efficient languages like Go or Rust. It would make self hosting more maintainable and break away from the consulting class that often has worse solutions at way higher prices (for an example, one consulting group sells software similar to postiz but for $2k/month).
By awongh 2026-03-1314:36 I guess there's the distinction between capacity that could be taken up by other things, and free capacity that doesn't necessarily cost anything.
For a server built in the cloud those cycles could actually be taken up by other things, freeing the system and bringing costs down.
For a client computer running electron, as long as the user doesn't have so many electro apps open that their computer slows down noticeably, that inefficency might not matter that much.
Another aspect is that the devices get cheaper and faster so today's slow electron app might run fine on a system that is a few years away, and that capacity was never going to be taken up by anything else on the end user's device.
I wonder what will be the parallel hindsight about waste, but for matrix multiplications, in a few years.
By xxpor 2026-03-1315:40 The economic incentives line up much better there. You charge for tokens -> cost is GPUs -> you work very hard to keep GPUs utilized 100% and get max tokens out of those cycles.
Compare this to essentially any modern business app, the product being sold has very little relationship with CPU cycles, or the CPU cycles are SO cheap relative to what you're getting paid, no one cares to optimize.
By then I understand that matrix multiplication will have cured cancer and invented unlimited free energy, so no hindsight of waste needed.
By echelon 2026-03-1313:25 Cure cancer? It doesn't have to cure cancer for it to make billions.
All it has to do is put price pressure on your salary. (And it is already doing that.)
By jillesvangurp 2026-03-1311:323 reply Build performance has been a pet topic for me for quite some time when I realized I was wasting so much times waiting for stuff to build 14 years ago. The problem is especially endemic in the Java world. But also in the backend world in general. I've seen people do integration tests where 99% of the time is spend creating and recreating the same database over and over again (some shitty ruby project more than a decade ago). That took something like 10 minutes.
With Kotlin/Spring Boot, compilation is annoyingly slow. That's what you get with modern languages and rich syntax. Apparently the Rust compiler isn't a speed daemon either. But tests are something that's under your control. Unit tests should be done in seconds/milliseconds. Integration tests are where you can make huge gains if you are a bit smart.
Most integration tests are not thread safe and make assumptions about running against an empty database. Which if you think about it, is exactly how no user except your first user will ever use your system.
The fix for this is 1) allow no cleanup between tests 2) randomize data so there are no test collisions between tests and 3) use multiple threads/processes to run your tests to 1 database that is provisioned before the tests and deleted after all tests.
I have a fast mac book pro that runs our hundreds of spring integration tests (proper end to end API tests with redis, db, elasticsearch and no fakes/stubs) in under 40 seconds. It kind of doubles as a robustness and performance test. It's fast enough that I have codex just trigger that on principle after every change it makes.
There's a bit more to it of course (e.g. polling rather than sleeping for assertions, using timeouts on things that are eventually happening, etc.). But once you have set this up once, you'll never want to deal with sequentially running integration tests again. Having to run those over and over again just sucks the joy out of life.
And with agentic coding tools having fast feedback loops is more critical than ever.
By panstromek 2026-03-1315:30 > Most integration tests are not thread safe and make assumptions about running against an empty database. Which if you think about it, is exactly how no user except your first user will ever use your system.
Yea, cypress has this in their anti-patterns:
https://docs.cypress.io/app/core-concepts/best-practices#Usi...
Dangling state is useful for debugging when the test fails, you don't want to clean that up.
This has been super useful practice in my experience. I really like to be able to run tests regardless of my application state. It's faster and over time it helps you hit and fixup various issues that you only encounter after you fill the database with enough data.
By Sammi 2026-03-1313:36 > I've seen people do integration tests where 99% of the time is spend creating and recreating the same database over and over again (some shitty ruby project more than a decade ago). That took something like 10 minutes.
For anyone that doesn't know: With sqlite you can serialize the db to a buffer and create a "new" db from that buffer with just `new Datebase()`. Just run the migrations once on test initialization, serialize that migrated db and reuse it instantly for each test for amazing test isolation.
By esafak 2026-03-1314:09 Kotlin compiles fast; I don't have any problems with ktor. Spring Boot and Rust do not.
By homebrewer 2026-03-138:293 reply Very pleased to see such performance improvements in the era of Electron shit and general contempt for users' computers. One of the projects I'm working on has been going for many years (since before React hooks were introduced), and I remember building it back in the day with tooling that was considered standard at the time (vanilla react-scripts, assembled around Webpack). It look maybe two minutes on a decent developer desktop, and old slow CI servers were even worse. Now Vite 8 builds it in about a second on comparable hardware. Another demonstration of how much resources we're collectively wasting.
> Very pleased to see such performance improvements in the era of Electron shit and general contempt for users' computers.
Luckily, we have invented a completely new nightmare in the form of trying to graft machine-usable interfaces on top of AI models that were specifically designed to be used by humans.
By itsTyrion 2026-03-1312:44 the vite Homepage lags on both an A55 and s23fe regardless, which bears at least some irony
It is especially weird because JavaScript was not supposed to be processed at all! This is all wrong if you ask me. Web development should strive to launch unchanged sources in the browser. TypeScript also was specifically designed so engine could strip types and execute result code. These build tools should not exist in the first place.
Steve Jobs decided differently when he hated on ActionScript.
10 years ago this sentence probably would have start a flame war. ;-)
Jobs’ complaint wasn’t actionscript the language, it was the security and performance nightmare of the Flash runtime.
Though it’s hard to imagine what the web would look like if the language had become the standard. JS is a pain but AS was even less suitable for general purpose compute.
And at least the "performance nightmare" is an irony from today's perspective as the Flash player wasn't actually slow at all! It was the incapability of the Safari browser to handle plugins in a good way and on mobile devices. Today's implementations of mobile application, JavaScript heavy applications and websites are much much more performance heavy.
ActionScript3 was a very suitable language.
By c-hendricks 2026-03-1315:19 Flash performance was also hit or miss on Linux.
By azangru 2026-03-1312:50 Probably wasn't supposed to either :-)
By tshaddox 2026-03-1314:59 > TypeScript also was specifically designed so engine could strip types and execute result code.
That's no less a build step than concating, bundling, minifying, etc. When people say "I'm against processing code before deploying it to a web site" but then also say "TypeScript is okay though" or "JSX is okay though," all they're really saying is "I like some build steps but not others." Which is fine! Just say that!
> TypeScript also was specifically designed so engine could strip types and execute result code. These build tools should not exist in the first place.
Was it? Have you forgotten namespaces and enums?
By MrJohz 2026-03-1313:19 More recently, it's been designed so this is the case. Namespaces, enums, and the property constructor shortcut thing were all added relatively early on, before the philosophy of "just JS + types" had been fully defined.
These days, TypeScript will only add new features if they are either JavaScript features that have reached consensus (stage 3 iirc), or exist at the type system only.
There have been attempts to add type hints directly to JavaScript, so that you really could run something like TypeScript in the browser directly (with the types being automatically stripped out), but this causes a lot of additional parsing complexity and so nothing's really come of it yet. There's also the question of how useful it would even be in the end, given you can get much the same effect by using TypeScript's JSDoc-based annotations instead of `.ts` files, if you really need to be able to run your source code directly.
If you're already passing over the sources to strip the types, why would you also not do tree-shaking and minifications?
Because it's a waste of bandwidth if they're not enforced at runtime, the same reason why minification exists.
By ZiiS 2026-03-1310:52 Both not minifying and including unenforced type hints consumes a little bandwidth though this can be largely offset by compression. This is an engineering trade off against the complexity of getting source maps working reliably for debugging and alerting. If I am shipping a video player or an internal company dashboard how much of my time is that bandwidth worth?
Maybe because TypeScript is not valid JavaScript (yet)? If you don't strip types, your code doesn't work.
By wildpeaks 2026-03-1312:25 It depends on the runtime: Node can run Typescript because it automatically strips types (which is so convenient during development).
But in browser, for now only the more limited JSDoc-style types can be shipped as-is indeed.
This feels like a ridiculous thread that captures everything wrong with modern Javascript ecosystem.
It's grown into a product of cults and attempted zingers rather than pragmatic or sensible technical discussions about what we should and shouldn't expect to be able to do with an individual programming language.
edit: to clarify, I assume there needs to be a basical level of comprehension of programming languages to debate the nuance of one, and if you can't think of a single reason as to why someone would want types removed, that's a possible indicator you don't have that necessary level yet, and I think the most effective way for you to learn that is to Google it. Sorry for coming across as rude if you genuinely don't know this stuff.
If you already know many reasons as to why types would be removed, then it seems disingenuous to ask that question, other than to make the point that you feel types shouldn't be stripped. If you think that, say it, and explain why you think they shouldn't be stripped.
By ZiiS 2026-03-1311:04 The current state of Javascript is you _have_ to remove types; I was pointing out I can think of reasons why I sometimes wouldn't want to. (Admittedly in a glib manor; though on this site many prefer that to four paragraphs)
By pestatije 2026-03-1310:54 How goes that saying?... always assume ignorance or malice will getcha
By mexicocitinluez 2026-03-1312:21 > It is especially weird because JavaScript was not supposed to be processed at all! This is all wrong if you ask me.
You're not actually suggesting that technology can't evolve are you? Especially one whose original design goals were to process basic forms and are now being used to build full-blown apps?
It's absolutely wild to me that with everything that has happened in the last 2 decades with regard to the web there are still people who refuse to accept that it's changed. We are building far bigger and more complex applications with JavaScript. What would you propose instead?
By k4rnaj1k 2026-03-138:54 [dead]
