前端工程化-Webpack 进阶-删除冗余代码、缓存

以下皆为拉勾教育课件内笔记

删除冗余代码（Tree Shaking）

简介

Tree Shaking 的作用是，打包时，删除未引用的代码（dead code）

何为未引用代码（dead code）：

return 后的代码
只声明，没有使用的代码
只引入，没有使用的代码

因为 Webpack 的依赖是⼀个树形结构，因此，删除无用代码的过程称之为摇树（Tree Shaking）。例如：下图中的函数 A 和函数 D 是未引用的代码。Webpack 打包时，会将其“摇”掉。

前提

使用 ES Modules 规范的模块，才能执行 Tree Shaking。这是因为 Tree Shaking 依赖于 ES Modules 的静态语法分析（即代码未执行之前，通过 export 和 import 来分析，哪些代码未引用）

使用

生产模式：Tree Shaking 自动开启
开发模式：usedExports 、sideEffects

usedExports

optimization.usedExports（标记没用的代码）
/* unused harmony export xxxxx */
terser-webpack-plugin（删除没用的代码）
optimization.minimize: true（删除 unused harmony export xxxxx标记的代码）
Webpack 4 需要单独安装（Webpack 5 无需安装）
详情查看：https://www.npmjs.com/package/terser-webpack-plugin

// webpack.config.js
// ...
const TerserPlugin = require("terser-webpack-plugin")

module.exports = (env, argv) => {
  // ...

  // 优化策略
    optimization: {
      // 标记未被使用的代码
      usedExports: true,
      // 删除 usedExports 标记的未使用的代码
      minimize: true,
      minimizer: [new TerserPlugin()]
    },

  // ...
}

Tree Shaking 与 Source Map 存在兼容性问题
想要使用 Tree Shaking，devtool 只能使用以下几种模式：
source-map | inline-source-map | hidden-source-map | nosources-source-map
eval 模式，将 JS 输出为字符串（不是 ES Modules 规范），导致 Tree Shaking 失效

sideEffects

sideEffects（副作用）

无副作用：如果一个模块单纯的导入导出变量，那它就无副作用
有副作用：如果一个模块还修改其他模块或者全局的一些东西，就有副作用
- 修改全局变量
- 在原型上扩展方法
- CSS 的引入

sideEffects的作用：把未使用但无副作用的模块一并删除

对于没有副作用的模块，未使用代码不会被打包（相当于压缩了输出内容），如果模块或函数有副作用，则不能随便删除。如下图，删除有副作用的函数，可能影响正在使用的 Fun C

开启副作用（webpack.config.js）

optimization.sideEffects: true

// webpack.config.js
// ...

module.exports = (env, argv) => {
  // ...

  // 优化策略
    optimization: {
      sideEffects: true,
      //...
    },

  // ...
}

标识代码是否有副作用（package.json）

''sideEffects''
- false：所有代码都没有副作用（告诉 webpack 可以安全地删除未用的 exports）
- true：所有代码都有副作用
- 数组：（告诉 webpack 哪些模块有副作用，不删除）例如：['./src/wp.js', '*.css']，数组中可以使用相对路径，绝对路径或正则。

// package.json
"sideEffects": [
  './src/wp.js', 
  '*.css'
],

缓存

缓存中主要涉及两个内容

Babel 缓存
文件资源缓存

Babel 缓存

cacheDirectory: true（第二次构建时，会读取之前的缓存）如下图：二次构建时，可能只有 tab.js，此时，我们可以只构建 tab.js，其他内容使用首次构建的缓存。

// webpack.config.js
module.exports = (env, argv) => {
  // ...
  // 模块配置
  module: {
    rules: [
      // ...
      {
        test: /\.m?js$/,
        exclude: /node_modules/,
        use: {
          // 第二次构建时，会读取之前的缓存
          cacheDirectory: true,
          // ...
        }
      },
      // ...
    ]
  }
  // ...
}

文件资源缓存

如果代码在缓存期内，此时，代码更新了，如果还是继续访问缓存中的旧文件。就看不到实时效果。方案：将代码文件名称，设置为哈希名称，名称发生变化时，就加载最新的内容。

Webpack 哈希值

[hash]（每次 Webpack 打包生成的 hash 值）
[chunkhash]（不同 chunk 的 hash 值不同 - 同一次打包可能生成不同的 chunk）
[contenthash]（不同内容的 hash 值不同 - 同一个 chunk 中可能有不同的内容）

比如在出口配置的文件名称中添加哈希值，也可以在加:数字限定哈希位数。

module.exports = (env, argv) => {
  // ...

  // 出口配置
    output: {
      // 输出目录（输出目录必须是绝对路径）
      path: resolve(__dirname, 'output'),
      // 输出文件名称（8位哈希值文件名）
      filename: '[name].[contenthash:8].js'
    },

  // ...
}

[hash]

只要源码发生变化，打包后，所有的文件名称都会发生变化。

[chunkhash]

源码发生变化后，打包时，只有跟变化相关的一路打包，打包后的文件名才会发生变化。

[contenthash]

源码发生变化后，打包时，只有跟变化相关的一个文件的文件名会发生变化。

由此可知，上述三种不同类型的哈希，对缓存的控制力度不同。