Jane said tree-shaking

       Tree-shaking is a relatively common word in the front-end field. What is its use in projects? I haven't figured it out before. After reading many blog posts, I tried it out in the project and figured out the general process. Here is a simple record.

First look at a piece of code

// app.js

export function A(a, b) {
    return a + b
}

export function B(a, b) {
    return a + b
}

// index.js

import {A} from '/app.js'

A(1, 2)

// 当index.js引用了app.js的A函数，如果tree-shaking起了作用，B函数是不会被打包进最后的bundle的。

       Ran goose, there is a sentence on the official website of webpack: rlies on the structure of ES2015 modules syntax, ieimport an export, the translation is that tree-shaking depends on the ES6 module input and output syntax. If your module introduction method is require, etc., tree- Shaking will not work.

       In the development and packaging, we commonly use the three artifacts of babel, webpack, and uglifyJs, and tree-shaking works in the first step. In the process of webpack processing js files, babel-loader first processes the js files , After processing, webpack will pack it up, and finally the code will be compressed by ugligyJs . There is a key configuration in babel's configuration file, which is preset:

{
  "presets": [
    ["env", {
      "modules": false  //关键点
    }],
    "stage-2",
    "react"
  ]
}

In this configuration, there is a module: false in the options of env. This is the key to instruct Babel how to deal with import and export. The default processing is in require form. If this option is added, then Babel will not convert import to require form , Creating conditions for webpack to perform tree-shaking.

        To sum up, in simple terms, tree-shaking is to delete useless code in the project and compress the project size.

The tree-shaking process of webpack on files is as follows:

       After determining that a block is useless, it will write a comment after processing, and uglifyJs will delete the code based on this comment

function(module, exports, __webpack_require__) {
    /* harmony export */ exports["foo"] = foo;
    /* unused harmony export bar */;

    function foo() {
        return 'foo';
    }
    function bar() {
        return 'bar';
    }
}

In the process of learning tree-shaking, you can perform tree-shaking on classes, which is more interesting. I found a demo to support tree-shaking:

1. First use loader to process, the code in the experimental phase is compiled into es code, so that the compiler inside webpack can correctly identify the code.

module: {
rules: [
  {
    test: /\.js$/,
    use: [
      {
        loader: 'babel-loader',
        options: {
          presets: ['babel-preset-stage-2', 'babel-preset-react']
        }
      },
      'eslint-loader'
    ],
    exclude: /node_modules/
  }
]
}

2. Pack through webpack and tree-shaking the code. After the packaged bundle, and before the output file, the final bundle is compatible.

plugins: [
    new UglifyJSPlugin(),  //  uglify要在babelPugin的前面
    new BabelPlugin({  //在这个插件内部进行最后bundle的兼容性处理
      test: /\.js$/,
      babelOptions: {
        presets: [env]
      }
    }),
    new webpack.DefinePlugin({
      'process.env.NODE_ENV': JSON.stringify('production')
    }),
    new HtmlWebpackPlugin({
      template: 'index.html'
    }),
  ]

The final summary steps:

1. First compile the experimental code into the standard code, which will involve the babel-preset-stage-x plug-in

2. webpack packs the code and performs tree-shaking recognition

3.uglifyjs performs code compression and deletes redundant code according to the webpack logo

4. Compatibility processing of the final code involves the babel-preset-env plugin

Tree-shaking of third-party libraries

After studying many third-party libraries, the basic conclusion is that tree-shaking cannot be performed on most third-party libraries.