At present, the business component library in the group because of some historical background reasons, source code and display site is divided into two independent project engineering maintenance, and the market for components, component library, tool library source code and site in a warehouse or the use of MonoRepo development and maintenance, Therefore, on the premise of not changing the project architecture (don’t worry about why they are not maintained together for the time being), we have carried out a series of evolutions in efficiency coordination and engineering. The following are the current problems we are facing:

Problems faced

npm link

Because source code and site maintenance are under two projects, how to associate the two projects in local development is the first problem we face. At first, we adopted the NPM Link method, but because the component library and site are developed based on React Hook, we need to go through the following steps every time for component iterative development:

  • CD node_modules/react && NPM link and CD node_modules/react-dom && NPM link
  • NPM link react && NPM link react-dom
  • Source: NPM link
  • Site below: NPM link source code

It is not hard to find that such a scheme has the following pain points (every new student involved in the development will tease diss) :

  • Cumbersome operation prone to error;
  • The combination of YARN and NPM causes link problems frequently.
  • The link is broken chain;

Site & source code, double compilation

For this release, we’ve ditched NPM Link altogether and taken a hack approach:

  • Source watch file changes, real-time compilation and construction of ESM;
  • Source watch ESM changes, real-time synchronization to the site node_modules;
  • ESM changes under watch node_modules, hot update;

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

  • Listen for node_modules changes, posture is hack;
  • Bilateral Watch + compilation, heavy consumption of memory resources;
  • Hot update time = component ESM compilation time + synchronous push time (negligible) + site compilation time, 10s+ no problem;

Site-by-site compilation

Since both the site and the source code have compile build capability, why not have one less compile build? To this end, we made a third optimization upgrade:

  • Source watch file changes, real-time synchronization source code to the site cache directory;
  • In the development environment, ESM under import node_modules is changed to component source under import cache directory;
  • The source code of components in the cache directory of watch site is changed and hot updated;

Although this upgrade has solved most of the problems, there are still problems.

Optimization of source code local development increases site compilation pressure:

  • Hot update slow: change a copy hotreload 2s +;
  • Cold startup is slower: 60s is fine

At this point the problem is somewhat common with webPack derivatives, so we are focusing on new build tools.

Why Vite?

Here I list a common build tool and some selection thinking.

The first is Webpack and its derivatives:

  • CRA encapsulated business scaffolding;
  • CRA.
  • Webpack lightweight configuration;

Webpack-based solutions are not very different from current scaffolders, the benefits are not obvious, and they do not fundamentally solve Webpack’s productivity problems.

Here are some of the most popular modern ESM-based solutions:

  • Snowpack
  • Vite

The article on comparing Utah is more convincing: contrast.

In addition, as far as I am concerned, THE university of Utah has a greater influence in the Chinese community as well as in China. Therefore, the open source tools of the University of Utah will be more active in the domestic community and attract more attention, which is beneficial to the subsequent sustainable development. Therefore, we choose Vite as the selection.

Results of earnings

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

Xi Da Pu Ben, significant effect!!

Why is Vite fast?

First cold start: Esbuild is precompiled and caches are generated

Cold start again: Leverage caching

Cold start

First of all, the reason why cold starts are faster is that Vite is based on native ESM, which means that Vite takes the work of building bundles before Webpack and hands it over to the most powerful browsers, so the cold start time is significantly reduced (after all, the most time-consuming cold start is analyzing the code to build bundles).

In Vite, as described in the official documentation, Vite divides our code atmosphere into dependency and source:

  • Dependencies: Mostly pure JavaScript that does not change at development time. Vite will pre-build dependencies using esBuild. Esbuild is written using Go and is 10-100 times faster than a prepacker-built dependency written in JavaScript
  • Source code: Usually contains files that are not directly JavaScript and need to be converted (such as JSX, CSS or Vue/Svelte components), often edited. Also, not all source code needs to be loaded at the same time (e.g. code modules based on route splitting)

“Bundle Based Dev Server”, represented by Webpack, relies on tools such as Babel to analyze the code and compile to generate runnable bundles before cold startup. This build-time process results in long cold startup time.

For “ESM Base Dev Server”, dev Server relies on our ESM, and our code itself is written in ESM, so we should inform dev Server target module path load, compile and parse to the browser runtime to deal with. Thus greatly speeding up our cold start.

Hot update

Based on native ESM

In Vite, HMR is executed on native ESM. Just like a cold start, when you modify a file, you don’t need to recompile it, so hot updates take much less time.

With an HTTP header

Vite makes full use of HTTP caching, which is one of the big differences we’ve seen in native development compared to WebPack. The network is full of module requests.

  • Source part: 304 with ETag negotiation cache

  • Dependent modules: strong caching

Webpack to Vite?

So how do you smoothly migrate from Webpack to Vite? In fact, 80% of Webpack scenarios are compatible when you land as a Vite document. Just consider a few additional cases:

ESM and ESM-derived issues

Vite uses esBuild to pre-build ESM, so the package requirements are relatively strict. Case by case processing is required for scenarios where esBuild precompilation fails.

Such as:

EsBuild precompilation failed. Procedure

Then the mode on a react-Virtualized windowScroll.js mode is implemented, which leads to a virtualized precompilation failure.

You can write esBuild plug-ins, write Resolutions, and pull local changes.

Dep-scan dependency analysis failed. Procedure

Take react-infinite- Scroller as an example. In package.json, the ESM reading directory points to the SRC source directory that is ignored after the package is sent, causing dep-Scan plug-in to fail to find modules.

ESNext bundle

The Vite build process is taken over by esBuild, and the lowest version of target supported by esBuild is ES6, so building a more compatible bundle requires either re-compiling Vite output or using the official SystemJS-based solution.

Here is a screenshot from the compatibility section of the Vite website:

Use the official plugin:

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

Said in the last

The demonstration site for our component library or the engineering project for our internal system is available, but we have to consider some issues when we actually put it into external projects:

The cost of

Switching from Webpack to Vite is cheap, even easier than upgrading to a larger version of Webpack. However, moving from Webpack to Vite is not just a conversion of build tools but a migration of the entire ecosystem, so the existing Babel plug-ins, Webpack plug-ins and so on need to be replaced equally for the historical project, which is a cost. In addition, as mentioned in the previous section, we also need to make additional adaptations for some non-standard tripartite packages, which is also a cost.

earnings

At present, Vite brings relatively high engineering efficiency benefits, but as far as I am concerned, what I try is only a simple display site, which can not be strictly equated with the actual business engineering, and enterprise project engineering volume and complexity are relatively large, whether Vite can meet the expected benefits I am not sure.

risk

Finally, as it relates to ESM, even if the SystemJs version is officially available, the actual compatibility risk of external projects is unknown.