As the number of modules included in the front-end application grows, the code packaging takes longer and longer. Many of the company’s projects take more than 10 seconds to package, and waiting for more than 10 seconds is uncomfortable for the average person, despite the speed of subsequent incremental edits. So I wanted to speed up the first packaging with the actual development environment.

1. Actual development environment

Most sites I come across in maintenance have the following features:

  • Huge number of modules
  • The module is mainly divided into JS module and CSS module, and less module is used lastextract-text-webpack-pluginPackage out a separate CSS file
  • The WebPack entry file contains JS and LESS, so you need to deal with js and LESS modules every time you pack
  • Many requirements only involve js module modifications, not style modifications. And vice versa.

2. Optimize your thinking

Since compiling less modules is not necessary in many cases, compiling JS modules separately in these cases can greatly improve WebPack performance. After all, compiling less and pulling out CSS are time-consuming.

3. Optimize steps

Optimization consists of the following two steps:

  • Separate compilation targets and compile JS separately? Or edit the CSS separately? Or js + CSS?
  • Entry files separate JS and CSS

3.1 Distinguish compilation objectives

This step is relatively easy, we need to use the cross-env plugin, for example, the following two build commands distinguish between compile JS and compile JS + CSS.

{
	"scripts": {
	    "build:js": "cross-env ctarget=all webpack"."biuld:js+css": "cross-env ctarget=js webpack"}}Copy the code

This allows us to distinguish the current compilation target in the webpack configuration file via process.env.ctarget.

3.2 Separating THE JS and CSS

This step needs to be implemented through the Loader of Webpack, which can use the existing wheel string-replace-loader.

The Loader can modify code at compile time and can be replaced with regular expressions. You can use it to load js files and then remove parts of the code. The following example removes all less code imports from the js file.

{
	module: {
		rules: [
			{
            test: /.js$/,
            use: (function(){
                var list = ['We can add any other loaders we need here']; // Delete the import of less for compilation purposesif (process.env.ctarget === 'js') {
                    list.push({
                        loader: 'string-replace-loader',
                        options: {
                            search: '^. +? require\\(.+(\\.less).+$',
                            replace: ' ',
                            flags: 'm'}})}returnlist; })()}]}Copy the code

If string-replace-loader is used, flags: ‘m’ must be used, otherwise multiple lines cannot be matched.

If we want to package CSS separately, we can write a loader that does the opposite of string-replace-loader, keeping only the style part and removing the rest of the JS code.

Effect of 4.

When tested in practice, this optimization can save up to 50% of the time. Of course, specific to each project depends on the ratio of JS to CSS modules.