background

Vite 2.0 has been released. As the first stable version of Vite 2, it’s time to take a closer look at Vite. The purpose of this article is to understand why Vite as a new generation of front-end development tools can greatly improve the speed of development build.

Introduction of Vite

Vite is a front-end build tool that integrates a development server and packaging tools out of the box. In contrast to traditional package build tools like Webpack, which package the build first and then start the development server, Vite takes advantage of the browser’s ESM support by starting the development server first (pre-build dependencies are performed on the first startup, as described below) and requesting the files for the corresponding modules when the code is executed and the modules are loaded. Requests to ESM modules have cross-domain problems). Official website image vivid:

ESM

ES6 finally provides module specifications at the language level, using ES Module as long as

  • Module code is only executed after loading
  • Modules can only be loaded once
  • A module is a singleton
  • A module can define a common interface on which other modules can observe and interact
  • Modules can request that other modules be loaded
  • Support for circular dependencies
  • ES6 modules are executed in strict mode by default
  • ES6 modules do not share a global namespace
  • The value of this at the top of the module is undefined (window in normal scripts)
  • The var declaration in the module is not added to the Window object
  • ES6 modules are loaded and executed asynchronously

We’ve already mentioned how browsers use ESM to get page resources. JS code can be divided into source code and dependent code. Source code is the main part of our work, and dependencies are referenced code. We use import React from ‘React’ to load dependencies. The ESM does not support loading bare modules. Vite will convert bare modules to absolute paths for us.

The weight of history

When I first started working with Vite, I had a question mark in my mind when I saw the use of esBuild pre-built dependencies. The page resource loading method described above has already solved the problem that the build-based server takes too long. Why build dependencies in the development server? After a careful reading of the document, it is not difficult to find:

Compatible with CommonJS and UMD

For historical reasons, many NPM packages are written as two modules with titles, and to be fast you have to bear the weight of history. Vite scans for dependencies, converts the two module modes of the title to ESM and cashes node_modules/.vite.

performance

Although the NPM package we introduced has only one entry file, as long as we use ESM, it will also involve the loading of modules. The result is to send requests to load JS files and find that module loads keep asking until all modules are loaded, and in extreme cases there are hundreds of subsequent requests for a module. In order to avoid too many requests affecting performance, Vite converts many internal module dependencies into a single module package caching node_modules/.vite. Since dependencies are largely unchanged, transformations that either accommodate older module solutions or resolve excessive requests generally occur on the first build.

conclusion

I believe you have a good idea why Vite is so fast

  • With the use of native ESM, there is no need to achieve a set of modular solutions compatible with various module standards, and the development server starts to use what resources request what resources, natural load on demand.
  • Use esBuild to turn a time-consuming build process into a much lighter reliance on pre-builds, speeding up builds tens of times faster.
  • Pre-built dependencies cache files, browsers request strong caching for dependencies, and other resource development servers negotiate caching based on whether changes are made.

reference

  • Vite official document
  • JavaScript Advanced Programming (version 4)