Vite 3.0 is out! | Vite

July 23, 2022 - Check out the Vite 4.0 announcement
In February last year, Evan You released Vite 2. Since then, its adoption has grown non-stop, reaching more than 1 million npm downloads per week. A sprawling ecosystem rapidly formed after the release. Vite is powering a renewed innovation race in Web frameworks. Nuxt 3 uses Vite by default. SvelteKit, Astro, Hydrogen, and SolidStart are all built with Vite. Laravel has now decided to use Vite by default. Vite Ruby shows how Vite can improve Rails DX. Vitest is making strides as a Vite-native alternative to Jest. Vite is behind Cypress and Playwright's new Component Testing features, Storybook has Vite as an official builder. And the list goes on. Maintainers from most of these projects got involved in improving the Vite core itself, working closely with the Vite team and other contributors.
Today, 16 months from the v2 launch we are happy to announce the release of Vite 3. We decided to release a new Vite major at least every year to align with Node.js's EOL, and take the opportunity to review Vite's API regularly with a short migration path for projects in the ecosystem.
If you are new to Vite, we recommend reading the Why Vite Guide. Then check out the Getting Started and Features guide to see what Vite provides out of the box. As usual, contributions are welcome at GitHub. More than 600 collaborators have helped improve Vite so far. Follow the updates on Twitter, or join discussions with other Vite users on our Discord chat server.
Go to vite.dev to enjoy the new v3 docs. Vite is now using the new VitePress default theme, with a stunning dark mode between other features.
Several projects in the ecosystem have already migrated to it (see Vitest, vite-plugin-pwa, and VitePress itself).
If you need to access the Vite 2 docs, they will remain online at v2.vite.dev. There is also a new main.vite.dev subdomain, where each commit to Vite’s main branch is auto deployed. This is useful when testing beta versions or contributing to the core’s development.
There is also now an official Spanish translation, that has been added to the previous Chinese and Japanese translations:
create-vite templates have been a great tool to quickly test Vite with your favorite framework. In Vite 3, all of the templates got a new theme in line with the new docs. Open them online and start playing with Vite 3 now:
The theme is now shared by all templates. This should help better convey the scope for these starters as minimal templates to get started with Vite. For more complete solutions including linting, testing setup, and other features, there are official Vite-powered templates for some frameworks like create-vue and create-svelte. There is a community-maintained list of templates at Awesome Vite.
Apart from the CLI’s aesthetics improvements, you’ll notice that the default dev server port is now 5173 and the preview server listening at 4173. This change ensures Vite will avoid collisions with other tools.
One of the pain points of Vite 2 was configuring the server when running behind a proxy. Vite 3 changes the default connection scheme so it works out of the box in most scenarios. All these setups are now tested as part of the Vite Ecosystem CI through vite-setup-catalogue.
Vite now avoids full reload during cold start when imports are injected by plugins while crawling the initial statically imported modules (#8869).
In Vite 2.9, both the scanner and optimizer were run in the background. In the best scenario, where the scanner would find every dependency, no reload was needed in cold start. But if the scanner missed a dependency, a new optimization phase and then a reload were needed. Vite was able to avoid some of these reloads in v2.9, as we detected if the new optimized chunks were compatible with the ones the browser had. But if there was a common dep, the sub-chunks could change and a reload was required to avoid duplicated state. In Vite 3, the optimized deps aren't handed to the browser until the crawling of static imports is done. A quick optimization phase is issued if there is a missing dep (for example, injected by a plugin), and only then, the bundled deps are sent. So, a page reload is no longer needed for these cases.
import.meta.glob support was rewritten. Read about the new features in the Glob Import Guide:
Multiple Patterns can be passed as an array
Negative Patterns are now supported (prefixed with !) to ignore some specific files
Named Imports can be specified to improve tree-shaking
Custom Queries can be passed to attach metadata
Eager Imports is now passed as a flag
The WebAssembly import API has been revised to avoid collisions with future standards and to make it more flexible:
Learn more in the WebAssembly guide
Most SSR frameworks in the ecosystem were already using ESM builds. So, Vite 3 makes ESM the default format for SSR builds. This allows us to streamline previous SSR externalization heuristics, externalizing dependencies by default.
Vite 3 now properly supports relative base (using base: ''), allowing built assets to be deployed to different bases without re-building. This is useful when the base isn't known at build time, for example when deploying to content-addressable networks like IPFS.
There are other deploy scenarios where this isn't enough. For example, if the generated hashed assets need to be deployed to a different CDN from the public files, then finer-grained control is required over path generation at build time. Vite 3 provides an experimental API to modify the built file paths. Check Build Advanced Base Options for more information.
One of the main differences between dev and build time is how Vite handles dependencies. During build time, @rollup/plugin-commonjs is used to allow importing CJS only dependencies (like React). When using the dev server, esbuild is used instead to pre-bundle and optimize dependencies, and an inline interop scheme is applied while transforming user code importing CJS deps. During