Hello everyone, this is Juice. I have been busy with the upgrading of the company’s structure in the beginning of the New Year, so THE writing of the article has been put on hold. I’m really sorry. I believe you see the title also know, yes! All of our projects were reconstructed with Vite, abandoning the cumbersome Webpack and embracing the new era of development. I wrote down all the potholes we encountered during the refactoring, and gave them back to the community in the hope that those who read this article would not repeat the potholes.

Why Vite?

If you have read my previous article, you should know that I have read the source code of vite1.x version. To be honest, vite was more like an experimental demo form at that time, and there was still a long way to go in terms of the production environment. But I was still paying attention to the project itself until February 17, 2021.17. Vite released 2.0.0-release

And the project itselfRollupDeep collaboration, refactoring the underlying code, introducing plug-in mechanisms,ViteAnd not just forVueService, becoming a true cross-framework development server.

Seeing this I think it’s about time! With more and more business, the local development of the project becomes less and less efficient, and it is intolerable to save the code and wait several seconds for webpack to be updated. Online packaging is also getting slower, seriously affecting iteration efficiency! Vite was the perfect solution to these pain points, so we decided to use Vite to rebuild the whole project in order to face the future business more easily.

Vite pit mining records

However, ideal is beautiful, reality slapped me in the face, because the ecology of Vite is not up, most of the problems actually need to be avoided, the following list of some of our project reconstruction encountered more obvious pits.

Uncaught ReferenceError: require is not defined

Question why

This is probably the one that comes up the most, because Vite is completely ESM native, meaning it only knows the import, because Vite relies on the Module property of script. Our code will eventually be sent to the browser to execute, require is the CJS keyword, the browser environment does not define this method, naturally error. Unlike WebPack, which prepackages the file before sending it to the browser, require has already been converted into a browser-compatible method.

The solution

At present, there is no particularly good method. If the module written by oneself uses require keyword, it needs to be replaced with import, but if it is a third-party module, there may be no solution if require is used in the package. Currently the packages encountered in the project include React-Intl, BizCharts, etc. If you also use these packages in your project, you can try to find a replacement package.

By the way, antD styles cannot be imported using css.js, because it uses the require keyword to refer to less files, and the browser will run in error.

None of the Node related methods are available

Question why

Node objects such as Process and event cannot be defined in the browser because they are sent directly to the browser without prior processing.

The solution

Polyfill can be done with the package of compatible browser in the community. Currently, process and event are mainly used in the author’s project, and process can be compatible with process-ES6.

import process from 'process-es6/browser.js'
// Assign to window in the browser
global.process = process
Copy the code

Events can be compatible with events. After installing events, you can do it without additional configuration.

xxx does not provide an export named ‘xxx’

Question why

Most third party packages are CJS exports, that is, only one export, such as Axios, jquery, LoDash, etc. They export in a similar way.

module.exports = require('./xxx');
Copy the code

Obviously, this is not recognized by Vite, because Vite only supports ESM export, and these third-party packages need to be compatible.

The solution

Fortunately, the official has provided a solution, please refer to this issue. ViteConfig provides the optimizeDeps parameter to handle CJS export packages, making them ESM exports, like this.

//viteConfig.js.optimizeDeps: {
    include: ['axios'.'jquery'.'lodash']},Copy the code

After the addition, the error is eliminated.

Failed to resolve entry for package ‘xxx’

Question why

The export location of some third-party packages in package.json is wrong, which leads to errors in Vite search.

The solution

Use the Resolve parameter of viteConfig to force the path to the correct address.

//viteConfig.js.resolve: {
    alias: [{find: 'intl-locales-supported'.replacement: path.resolve('node_modules/intl-locales-supported/src/index.ts')}}]Copy the code

Static resource directory problem

Question why

The default static directory of Vite is public. If you need to define other directories, this will not take effect.

The solution

Use viteConfig’s publicDir parameter to change the static directory to the one you want.

//viteConfig.js.publicDir: 'static'.Copy the code

alias ‘@’ to path.resolve(__dirname, ‘./src’) is not working

Question why

Since Vite already uses @ for module import, using the @ alias as an absolute path can be problematic

The solution

Avoid @ conflicts by adding a /, see this issue for details

// vite.config.js
module.exports = {
  alias: {
    '/ @ /': path.resolve(__dirname, './src')}}Copy the code

compatibility

Vite defaults to using the browser’s native module capabilities, which means that it requires modern browser support. Below are the lowest supported browser versions

Chrome >=61
Firefox >=60
Safari >=11
Edge >=16
Copy the code

That said, none of these versions will support the Module attribute. Fortunately, our project does not need to support older browsers, such as Versions of Internet Explorer, which is one of the reasons why we dare to refactor.

@vitejs/ plugin-Legacy allows Vite packaged projects to run in older browsers, using @babel/preset-env for conversion, which is slowed down. It’s a trade-off.

Replace advice

If one of the following points is true, I recommend not substituting

  1. If the project has a lot of historical baggage and a lot of miscellaneous code, replacement can be costly and may ultimately fail.
  2. If the browser has high compatibility requirements, for example, it needs to be compatible with old Versions of Internet Explorer.
  3. Currently there is not that much packaging pressure on projects and local development efficiency is ok.
  4. Using some special plugins,ViteThere are no comparable substitutes.

If you don’t have any of the above questions, I think Vite is still worth a try. The development experience is really great, the response is millisecond, and you feel really hot updates. Packing also dropped from three minutes to 50 minutes.

Write in the last

Vite as a competitive product of Webpack, I think the future is promising, although the ecology is not perfect, but as long as the community is active enough, one day it can create its own day, let’s look forward to that day