Since the release of Vite 2.0 in February 2021, the number of users of the Vite project has grown very rapidly, and soon reached 1 million npm downloads per week, becoming one of the projects with the highest npm downloads . At the same time, Vite's community is becoming more and more active, and has formed a very large community ecology, which has brought many changes to the entire front-end field, such as:
- Major front-end frameworks including Nuxt 3, SvelteKit, Astro, StoryBook, etc. have adopted Vite as a built-in construction solution.
- The Vite-based testing tool Vitest was born, becoming a new generation of testing solutions to replace Jest.
It is now July 2023, and the Vite 4.0 version has been launched for several months, but we still want to introduce some changes brought by Vite 3.0.
1. Brand new VitePress documentation
For the user side, when it comes to updating the framework, documentation is naturally the most important part. Now you can go directly to the vitejs.dev site to experience the v3 version of the documentation. Currently, the documentation is also built using VitePress.
Not only Vite, but also some other projects in the Vite ecosystem use VitePress to build document sites, such as Vitest , vite-plugin-pwa and VitePress ' own documents. I also highly recommend everyone to use VitePress as one of their document site building solutions.
2. Updates in the development phase
2.1 Updates to the CLI
When executing the vite command to start the project, the interface of the terminal will be different from before, and more importantly, in order to avoid the port conflict between the Vite development service and other applications, the default port number has changed from 3000 to 5173.
2.2 Out-of-the-box WebSocket connection strategy
There is a pain point in Vite 2, that is, in the presence of a proxy (such as Web IDE), we need to manually configure WebSocket to make HMR take effect. Currently, Vite has built-in a more complete set of WebSocket connection strategies to automatically meet the HMR requirements of more scenarios.
2.3 Service cold start performance improvement
Vite 3.0 has done a lot of work on service cold start to maximize the speed of project start. First of all, let's take stock of some problems of service cold start in Vite 2.x stage.
From Vite 2.0 to version 2.9, Vite will pre-build dependencies before the service starts, that is, use Esbuild to scan out the dependencies used in the project (Scan), and then package them once (Optimize).
However, this creates two problems:
- Relying on pre-build will block Dev Server startup, but Dev Server can start normally without blocking.
- When some Vite plugins manually inject import statements, such as calling babel-plugin-import to add import Button from 'antd/lib/button', it will lead to secondary pre-build of Vite, because the import code of antd/lib/button is created by Vite plug-in injection is a dependency found when the Dev Server is running, and cannot be scanned during the cold start phase.
The so-called secondary pre-build includes two steps. One is to pre-build all dependencies in full, and the other is to reload the page to load the latest dependent code due to dependency updates. This will lead to a significant decline in the performance of the Dev Server, especially in scenarios where there are many new dependencies, and it is easy for the browser to get stuck.
And vite-plugin-optimize-persist is to solve the problems caused by the second pre-build, and record the dependencies scanned by the Dev Server runtime in a persistent way, so that the first pre-build can be perceived and avoid the second pre-build happened.
In version 2.9, Vite has refactored the pre-built logic as a whole, and the final effect is as follows:
-
After the Dev Server is started, the pre-build (Optimize phase) is executed in the background, that is, the pre-build no longer blocks the start of the Dev Server, and only needs to wait for the Scan phase to complete, but usually the overhead of this phase is very small.
-
If some dependencies are only discovered when the Dev Server is running, Vite will reuse the existing pre-built products as much as possible, and try not to reload them.
Is that problem completely solved? In fact, it is not. In some scenarios, Vite still inevitably needs a second pre-build. As in the following example:
Both A and B are third-party dependencies of the project, and they also depend on C. Then when Vite pre-builds A, it will package A and C together. However, Vite found that it depends on B at runtime, and A and B need to share the code of C, so the code of C may be extracted into a common chunk, so the pre-built product of A may have changed before, then At this time, Vite must forcibly refresh the page to let the browser use the latest pre-built product. This is still a secondary pre-build (all dependencies repackaged + page reload) process. Overall, version 2.9 solves the problem of pre-build blocking service startup, but does not completely solve the problem of secondary pre-build.
But in Vite 3.0, the problem of secondary pre-build has also been fundamentally solved. How did Vite 3.0 do it?
The core solution is to delay processing, that is, to delay the pre-build behavior until the final stage of page loading. At this time, Vite has compiled all source files, and can accurately record all dependencies that need to be pre-built (including Vite plug-ins added Some dependencies), and then pre-build uniformly, and respond to the pre-built product to the browser.
Therefore, compared with Vite 2.0, Vite 3.0 optimizes in the cold start phase mainly in two aspects:
- Pre-build will no longer block the startup of Dev Server, and truly achieve the effect of service startup in seconds;
- Fundamentally prevent the occurrence of secondary pre-build.
2.4 import.meta.glob syntax update
Vite 3.0 rewrites the implementation of import.meta.glob, supports a more flexible glob syntax, and adds the following features:
- Multiple pattern matching
import.meta.glob(["./dir/*.js", "./another/*.js"]);
- Negative pattern (!)
import.meta.glob(["./dir/*.js", "!**/bar.js"]);
- Named imports can better do Tree Shaking
import.meta.glob("./dir/*.js", { import: "setup" });
- Custom query parameters
import.meta.glob("./dir/*.js", { query: { custom: "data" } });
- Specify eager mode, replace the original import.meta.globEager
import.meta.glob("./dir/*.js", { eager: true });
3. Update of the production stage
3.1 SSR products use ESM format by default
In the current community ecology, many SSR frameworks are already using the ESM format as the default product format. Vite 3.0 also actively embraces the community and supports SSR to build products that are packaged in ESM format by default.
3.2 Relative Base support
Vite 3.0 officially supports Relative Base (that is, configure base: ''), which is mainly used in scenarios where the base address cannot be determined during construction.
In general, Vite 3.0 brings some relatively large architectural changes, such as relying on pre-built refactoring, supporting production environment Esbuild pre-packaged dependencies, and fully supporting Pure ESM. Of course, there are also some relatively small break changes in this version set Releases, such as changes to import.meta.glob syntax.