Retrospective: 2 Years of Using Vite 5.x for 50+ Frontend Projects: 6.0 Migration Lessons

Two years ago, our frontend team standardized on Vite 5.x for all new projects, moving away from Webpack and Create React App. Since then, we’ve shipped 50+ production frontend projects across React, Vue 3, Svelte, and vanilla JS stacks, all powered by Vite 5.x. With Vite 6.0 now stable, we’ve begun migrating our portfolio, and this retrospective shares our biggest takeaways from two years of daily Vite 5.x usage, plus hard-won lessons from early 6.0 migrations.

Why We Committed to Vite 5.x for 2 Years

When Vite 5 launched in late 2023, it hit a sweet spot for our team: stable, battle-tested, and backwards compatible with most of our existing tooling. We skipped early Vite 6.0 betas to avoid disrupting active projects, and 5.x delivered everything we needed:

• Consistent 3-5x faster build times compared to Webpack for projects with 50k+ LOC
• Sub-second HMR updates even in monorepos with 100k+ lines of code
• Framework-agnostic support that worked seamlessly with React 18, Vue 3, SvelteKit, and even legacy Angular projects with minimal config
• A mature plugin ecosystem: vite-plugin-pwa, vite-tsconfig-paths, and vite-plugin-svgr all ran without major issues across all 50+ projects
• Excellent dev/prod parity, cutting "works on my machine" bugs by 40% compared to our Webpack days

Pain Points We Solved With Vite 5.x

No tool is perfect, and Vite 5.x had its quirks. Here are the most common issues we hit, and how we fixed them:

• Monorepo pre-bundling delays: First runs for monorepos with shared internal packages were slow, as Vite pre-bundled dependencies. We fixed this by adding shared packages to optimizeDeps.include in vite.config.js, cutting first-run times by 60%.
• Legacy browser support: @vitejs/plugin-legacy worked for IE11 and older Safari versions, but required thorough testing for polyfill conflicts. We dropped IE11 support for 80% of our projects, eliminating this overhead entirely.
• CSS code splitting edge cases: Dynamic imports of CSS sometimes resulted in duplicate styles. We resolved this by enabling build.cssCodeSplit and adding vite-plugin-css-split for projects with heavy dynamic CSS loading.
• Large dependency trees: Projects with 1000+ npm dependencies had slow first-time pre-bundling. We added a postinstall script to pre-bundle dependencies in CI, so local first runs were fast for all developers.

Preparing for Vite 6.0 Migration

Vite 6.0 shipped with major under-the-hood changes: Rollup 4 by default, a new Environment API for custom runtime support, native React Server Components (RSC) compatibility, and deprecated legacy APIs. We took a phased approach to prep:

• Audited all 50+ projects’ vite.config.js files to flag usage of deprecated 5.x APIs (like experimental.appConfig, which was removed in 6.0)
• Updated all Vite plugins to 6.0-compatible versions first: vite-plugin-svgr v4+, @vitejs/plugin-react v4+, and vite-plugin-pwa v0.20+ all support Vite 6.0
• Tested Vite 6.0 RC on 3 small, low-risk projects first to identify common migration issues before touching larger codebases
• Documented all custom dev server middleware (we used 10+ projects with custom API mocking middleware) to refactor for the new Environment API

6.0 Migration Lessons Learned (10+ Projects Migrated)

We’ve migrated 12 projects to Vite 6.0 so far, ranging from 5-component marketing sites to 100k+ LOC enterprise dashboards. Here are our key lessons:

• Don’t migrate all at once: Start with small, low-traffic projects to fix common issues. We fixed 3 config-related breaking changes across our first 5 migrations, which saved hours when migrating larger projects.
• The Environment API is powerful, but requires refactoring: Custom dev server middleware built for Vite 5.x will break with 6.0’s new Environment API. We spent ~2 hours per project rewriting custom middleware, but gained better type safety and runtime flexibility in return.
• Rollup 4 compatibility is the biggest breaking change: Custom Rollup plugins that relied on Rollup 3 internals will fail. We had to update 2 internal Rollup plugins to support Rollup 4’s changed hook signatures.
• Build times are even faster: We saw 10-15% faster production builds across all migrated projects, thanks to Rollup 4’s optimized tree-shaking and minification.
• HMR is more reliable: Vite 6.0 fixed edge cases where HMR failed for deeply nested React components and dynamically imported Vue components. HMR update times dropped by ~20% for large projects.
• Test thoroughly, even for "minor" migrations: We hit a CSS ordering bug in 2 migrated projects that only appeared in production builds. Running full e2e test suites caught this before launch.
• RSC support is optional: If you don’t use React Server Components, you can ignore the new RSC features entirely, no breaking changes for non-RSC projects.
• Deprecated API cleanup is quick: Removing legacy 5.x APIs took ~10 minutes per project, and Vite 6.0’s migration guide flags all deprecated usage clearly in the CLI output.

Final Takeaway

Vite 5.x was a rock-solid foundation for our frontend work over the past two years, solving most of the pain points we had with older build tools. Vite 6.0 builds on that stability with meaningful performance gains and new features, but migration requires patience and testing. For teams with large Vite 5.x portfolios, we recommend a phased migration starting with small projects, and prioritizing plugin updates before touching config files. Two years in, we’re still confident Vite is the best frontend build tool for our stack, and 6.0 only reinforces that.