Speed up your productivity with Vite

At present, the business component library in the group is divided into two independent project maintenance for the source code and display site due to some historical background reasons, and the source code and site of the component, component library, tool library on the market are maintained in one warehouse or MonoRepo is used. Therefore, we have made a series of evolutions in terms of efficiency coordination and engineering without changing the project structure (for the time being, don’t worry about why we don’t put them together for maintenance). Let’s first introduce the current problems we face. :

the problem we are facing

npm link

Because the source code and site are maintained under two projects, how to associate the two projects when developing locally is the first problem we face. Initially, we adopted the npm link method, but because the component library and the site are both developed based on react hook , So every time you perform component iterative development, you need to go through the following steps:

• Under the site: cd node_modules/react && npm link and cd node_modules/react-dom && npm link
• Source code: npm link react && npm link react-dom
• Source code: npm link
• Under the site: npm link source code

It is not difficult to find that such a solution has the following pain points (every new student participating in the development will complain about diss):

• The operation is cumbersome and error-prone;
• The mixed use of yarn and npm makes link problems frequently;
• link Broken link;

Site & source code, dual compilation

In this version, we completely abandoned npm link and adopted a more hacky approach:

• Source watch file changes, real-time compiling and building ESM;
• The source code watch ESM changes, synchronized to the site node_modules in real time;
• The component ESM under the watch node_modules site is changed and hot updated;

It is not difficult to find that such a scheme has the following pain points:

• Monitor node_modules changes, the posture is very hack;
• Double-sided watch + compilation, which seriously consumes memory resources;
• Hot update time = component ESM compilation time + synchronization push time (can be ignored) + site compilation time, 10s + proper;

Site single compilation

Since both the site and the source code have the ability to compile and build, why not reduce one compile and build? To this end, we carried out the third optimization and upgrade:

• The watch file of the source code is changed, and the source code is synchronized to the site cache directory in real time;
• In the development environment, the ESM under the import node_modules site is changed to the component source code under the import cache directory;
• The source code of components in the watch cache directory of the site is changed and hot updated;
  Although most of the problems have been resolved after this upgrade, there are still problems.

The optimization of the source code local development makes the site compilation pressure increase:

• Slow hot update: change a copy of hotreload 2s +;
• Cold start is slower: 60s is safe;

In fact, up to now, the problem has to a certain extent relied on the common problem of the webpack derivative solution. Therefore, we have focused on the new build tool.

Why choose Vite?

Below I list a common construction tool and some selection thinking.

The first is Webpack and its derivative solutions:

• Business scaffolding based on CRA package;
• CRA；
• Webpack lightweight configuration;

The Webpack-based solution is not much different from the scaffolding currently used, the benefits are not obvious, and the productivity problems caused by Webpack cannot be solved fundamentally.

Next is the current popular modern ESM-based solution:

• Snowpack
• Vite

More convincing articles about the larger ones: vs. .

In addition, personally, I think Yoda has a greater influence in the Chinese community and in the country. Therefore, Yoda’s open source tools will be more active in the domestic community and will be more concerned. For follow-up Sustainable development is also more favorable, so we chose Vite in the selection.

Achievements and benefits

• Second-level cold start: 60s+ => 3s- (about 300ms after the cache takes effect)
• Millisecond hot update: 2s+ => 1s- (sync + hotreload)

Hi Da Pu Ben, the effect is remarkable! ! !

Why is Vite fast?

First cold start: esbuild pre-compiled, cache generation

Cold start again: use cache

Cold start

First of all, why is the cold start fast? Because Vite is based on native ESM, which means that Vite delegates the original Webpack pre-build bundle work to the powerful current browser, so the cold start time is greatly reduced (after all, cold start is the most time-consuming It is to analyze the code to build a bundle).

In Vite, as the official document introduces, Vite divides our code atmosphere into two parts: dependency and source code:

• Dependence: mostly pure JavaScript that will not change during development. Vite will use esbuild to pre-build dependencies. esbuild is written in Go and is 10-100 times faster than packager pre-built dependencies written in JavaScript
• Source code: usually contains some files that are not directly JavaScript, need to be converted (such as JSX, CSS or Vue/Svelte components), and are often edited. At the same time, not all source code needs to be loaded at the same time (for example, code modules based on route splitting)

The "bundle based dev server" represented by Webpack needs to rely on tools such as babel to analyze the code and compile to generate a runnable bundle before the cold start. The construction caused the cold start time to be too long. long.

For "ESM base dev server", the dev server relies on our ESM, and our code itself is written in ESM, so we need to tell the dev server to load the target module path when we go in, and the compilation and analysis will be handed over to the browser. runs to process, which greatly accelerates our cold start.

Hot update

Based on native ESM

In Vite, HMR is executed on the native ESM. Just like the cold start, when we modify a file, we don't need to recompile, and the hot update will greatly reduce the time-consuming.

With http header

Vite makes full use of the http cache, which is also a big difference from webpack that we have seen during local development. The network is full of module requests.

• Source code part: 304 Cooperate with ETag to negotiate caching

• Dependent module: strong cache

Webpack to Vite ？

So how to smoothly migrate from Webpack to Vite? In fact, when you follow the Vite documentation, you are already compatible with 80% of Webpack scenarios. Just need to consider some additional cases:

ESM and ESM derivative issues

Vite uses esBuild to pre-build ESM, so the requirements for packages are relatively strict. For scenarios where esBuild pre-compilation fails, case by case needs to be handled.

E.g:

esBuild precompilation failed

Taking react-virtualized as an example, the introduction of flow type files under react-virtualized WindowScroll.js caused pre-compilation failure.

You can write esBuild plugins, write resolutions, and pull packages to make local changes.

dep-scan dependency analysis failed

Take react-infinite-scroller as an example. The ESM read directory in package.json pointed to the src source directory that was ignored after the package was sent, causing the dep-scan plugin to fail to find the module.

ESNext bundle

The Vite build process is taken over by esBuild, and the minimum version of the target supported by esBuild is es6. Therefore, if you want to build a more compatible bundle, you need to recompile the output of Vite or use the official SystemJS-based solution.

The following picture is a screenshot of the compatibility section of the Vite official website:

Use the official plugin:

• Babel translates and registers it as a System.js module;
• Add System.js runtime;

Said at the end

The display site of our component library or the engineering project of the internal system can be used as soon as it is used, but we have to consider some issues when actually investing in external projects:

cost

Simply speaking, the cost of switching from Webpack to Vite is very low, and it is even simpler than a major version upgrade of Webpack. However, the transition from Webpack to Vite is not only the conversion of the build tool but the migration of the entire ecology, so the existing babel plugins and Webpack plugins of historical projects need to be replaced in equal amounts, which is a cost. In addition, as mentioned in the previous section, we also need to make additional adaptations for some irregular tripartite packages, which is also a cost.

income

From the current point of view, the engineering efficiency and benefits brought by Vite are relatively high, but personally, what I tried is only a simple display site, which cannot be strictly equated with actual business engineering, and the amount and complexity of enterprise-level projects Both are relatively large. I personally cannot guarantee whether Vite can meet the expected benefits.

risk

Finally, because ESM is involved, even if the official SystemJs version of the compatible plug-in is given, the compatibility risk of the actual investment in external projects is still unknown.