Webpack multi-page project to Vite upgrade initial attempt

This article has participated in the call for good writing activities, click to view: back end, big front end double track submission, 20,000 yuan prize pool waiting for you to challenge!

Recently, the community has been talking about Vite, and I have heard that it is a “fast shooter”, as a cutting tool to represent efficiency, with the expectation of fast and improve my vision (bragging ability), try using Vite to upgrade an existing WebPack-based multi-page project.

This article gives you an idea of how Vite compares to Webpack. Here’s what you’ll learn:

• Why Vite is so hot
• What are the advantages of Vite
• What are the downsides of Vite
• Upgrade process pit
• Improved project after upgrade (visualize package speed, visualize hot update speed, visualize package volume)

The appeal of Vite

What makes Vite so coveted? When I first heard about Vite they said it was really fast, but everyone is a packaging tool, why is Vite faster than Webpack? Here’s how Vite is officially introduced:

• Fast service startup, using native ESM files, no packaging required!
• Lightweight fast thermal overloading, always extremely fast module thermal overloading (HMR) regardless of application size
• Rich functionality for TypeScript, JSX, CSS, and more out of the box.
• Optimized build, optional “multi-page application” or “library” mode pre-configured Rollup build
• A generic plug-in that shares the Rollup-superset plug-in interface between development and build.
• Full typed apis, flexible apis, and full TypeScript types

Let’s create a new Vite demo and use

yarn create vite
Copy the code

When you’re done, you’ll see that the root directory has an index. HTML. Unlike Webpack, Vite is based on HTML as the entry, while Webpack is based on Js as the entry. In HTML we see a Vite built project script that uses type=”module”. What is this? ES Modules is the ECMAScript standard for handling Modules. By setting type=”module”, we can write code using import Export in the current script support.

Almost all modern browsers already support the ESM approach

This is the secret of Vite’s speed. Vite uses ESM and KOA middleware to intercept requests so that we can introduce a module dynamically (with import()) only when we need it, without having to pack it in advance. This is completely different from Webpack, which packs modules into bundles ahead of time, but the packaging process is static, meaning that after changing one part of the code, all modules are packaged. The downside of this is that as the project gets bigger and bigger, the bundles get bigger and bigger. (Of course, Webpack has a lot of plugins like able-cache to improve efficiency.) Webpack still does the packaging, which is really less elegant than Vite. ESM eliminates the need for packaging.

advantages

1. Create a simple

Vite inherits the good tradition of Vue and focuses on improving development efficiency, so there is a lot less configuration compared to Webpack. With Vite, you no longer configure the various basic preprocessors, it is built in

2. Frame independent

Although its author is the creator of Vue, Vite is framework independent and can be used with React, Vue, Svelte, Preact, etc

disadvantages

1. flexible

Because its internal encapsulation of a lot of things, so now it seems that customization is more difficult, this point is to see their own trade-offs, each has pros and cons.

2. unaware

Now Vite2 has not come out for a long time, the community has not many large-scale project practices, whether there are still many pits to be seen

3. Build inconsistency

This is also what I am most worried about. ESM is used for development while Rollup is used for packaging. That is to say, if two sets of methods are used, there will be a discrepancy between the production environment and the development environment, which will lead to bad bugs after packaging. In-depth testing of projects that are migrated later is required.

The program

Because our project was upgraded from the old manual packaging to Webpack packaging, most of the pages themselves used HTML, so the migration cost was relatively small, mainly by inserting script type=module code into the original HTML

Problems encountered during migration:

1. In the past, some image resources introduced by require cannot be used and need to be changed to import. This is because the Vite development environment is based on ESM and does not support CommonJs
2. In the past, we had no specific rules about how to use environment variables. In Vite, to prevent accidental leakage of environment variables to the client, only variables prefixed with VITE_ are exposed to Vite code (similar to CRA), and we do not use process.env to obtain environment variables. Instead, import. Meta. Env.
3. Vite is packaged by default for ESM compatibility, here we need to install @Vitejs/plugin-Legacy to handle unsupported browser handling

The whole project migration took less than 2 hours, and most of the time was spent processing modules and resources introduced through require. Whether the packaged files can be used in the production environment remains to be determined. ESM mode will still be introduced after packaging, but NoModule loading mode will be added after ESM. The advantage of this is that in modern browsers we don’t have to load so many polyfills, reducing unnecessary resource loads. As follows:

Project promotion

Test environment Window10 8G I5-6200U

The single page test used the page with the most resources and dependencies in the project (image resources 100+, JS files 20+);

The packaging efficiency is basically the same, because there is little difference between Webpack and Rollup in packaging, the advantages in packaging are not so prominent, and the packaging volume is similar, so there is no comparison here.

conclusion

Completed the project migration, to have a general understanding of Vite, there are many pits in compatibility configuration, can continue to use Webpack for packaging, and in the development environment using Vite development may also be a good match. The next step is to do a detailed understanding of the Vite configuration and test the project to see if there are any unexplored pits. In the future, we will continue to wait and see for Vite, hoping that one day we can do away with all kinds of packaging tools and how nice native support will be.