1. TreeShaking

Tree shaking is a term used to describe removing dead-code from a JavaScript context. It relies on static structural features in the ES2015 module system, such as import and export

1.1 Problem Introduction

We’ll add a new tool file called math.js to add and minus methods:

//math.js

export const add = (a,b) =>{
    console.log(a+b)
}

export const minus = (a,b) => {
    console.log(a-b)
}
Copy the code

Then import from index.js:

// index.js
import {add} from './math.js'

add(1,2)
Copy the code

Then we built and packaged, and found that the files at the back end of the package included not only the code of Add but also the unused minus-related code.

This is not necessary, it will make the JS file bigger, the ideal situation is to introduce what is really used, you help me pack what.

This is the tree shaking feature that Webpack provides – shaking out the parts of a module that are not useful, leaving only the parts that are needed.

1.2 Configuration and Usage

Tree Shaking only supports ES Modules (import, export). It does not support CommonJS (require (./)).

This is because the former is based on a static introduction at the bottom, while the latter is dynamic and cannot be supported in the packaging phase.

Let’s look at the webpack configuration file. Tree shaking is not enabled by default when mode is development.

optimization:{
    usedExports:true
}
Copy the code

Then we need to go to package.json and configure it again:

{... "sideEffects":false, ... }Copy the code

See this blog post for details on the relationship between sideEffects configuration items and treeShaking

The tree shaking may be shaken off when your import object is not intended to be used, but when you do something extra, such as importing polyfill.

{... "sideEffects":["@babel/polly-fill"], ... }Copy the code

Previously we avoided importing polyfill directly by configuring the useBuiltIns field, so we can change this to false.

It is also possible to import some CSS files, and tree shaking will kill them, so we would normally write a CSS rule here:

{... "sideEffects":["*.css"], ... }Copy the code

After repackaging, we found that the bundle still had the minus code, but the exports used:minus comment was gone.

This is because we are currently in a development environment and need to do some debugging, and if Tree Shaking dies, sourcemap will fail and cannot be debugable.

In production, tree shaking is added automatically. The new configuration is not needed.

After repackaging, he searched and found that he could not find the relevant code of Minus.

2. buildMode

In fact, this point has been mentioned before, is to set the packaging mode field, including development and production

Previously, we used devServer and HMR technologies in the development process, which was very convenient. However, once the source code was developed and needed to be put online, mode should be changed to production.

SourceMap under Development is complete, while Produciton can generate a map file for storage.

The code under Development is not compressed and the source code is fully visible, whereas Produciton is compressed

2.1 Write configuration files for different modes

If we need to change the configuration of the previous mode, we have to manually modify it in webpack.config.js, which is quite tedious (and some configurations may be different in different modes).

To solve this problem, we can solve it as follows:

  1. First rename webpack.config.js -> webpack.dev.js.
  2. Then a new webpack.prod.js file is created, corresponding to the configuration items in dev and PROd respectively. The changes required by the prod configuration item file are mainly to remove the previous configuration items related to devServer, HMR and Optiimaztion.
  3. Configure package.json file and add the corresponding script:
. scripts:{ "dev":"webpack-dev-server --config webpack.dev.js", // devServer "build":"webpack --config webpack.prod.js"Copy the code

Directly NPM run dev during development, start a devServer to cooperate with HMR to improve development efficiency.

The NPM run build is then executed when the development is finished and goes live. The HTML and packaged JS files used on the line can be generated under the dist directory

2.2 Configuring Encapsulation

In this case, we create a webpack.common.js file and extract the common code into it, such as entry, Module, output, Although the values of the plugins and plugins are somewhat different, the common parts can still be extracted:

Prod configuration file after extraction:

module.exports = {
    mode:'production',
    devtool:'cheap-module-source-map'
}
Copy the code

The extracted dev configuration file:

const webpack = require('webapck')

module.exports = {
    mode:'development',
    devtool:'cheap-module-eval-source-map',
    devServer:{
        contentBase:'./dist',
        open:true,
        port:8080,
        hot:true
    },
    plugins:[
        new webpack.HotModuleReplacmentPlugin()
    ],
    optimization:{
        usedExports:true
    }
}
Copy the code

Extract encapsulated common.js:

Const path =... const path =... const HtmlWebpackPlugin = ... . module.exports = { entry:... , module:... , export:... . }Copy the code

This is not enough, remember to merge dev.js and prod.js with common.js, where we need to use a third party module: webpack-merge

npm install -D webpack-merge
Copy the code

Merge webPack-merge and merge commonConfig

// webpack.dev.js const merge = require('webpack-merge'), const commonConfig = require('./webpack.common.js') const devConfig = { ... } module.exports = merge(commonConfig,devConfig)Copy the code

2.3 tip

Some frameworks create an extra build folder and place all three webpack configuration files in the Build folder.

Remember to change the script path as well