各位观众，大家好！我是今天的讲师，咱们今天聊聊JS Tree Shaking这档子事儿，以及它背后的"sideEffects"配置，看看怎么把它玩转，榨干最后一滴性能。
第一幕：Tree Shaking，听起来很环保！
Tree Shaking，翻译过来就是“摇树”，听起来很田园牧歌是不是？实际上，它是一种死代码消除（Dead Code Elimination）技术，简单来说，就是把JS代码中没用到的部分给摇掉，打包的时候就不用带上它们了。就像你整理行李，把那些“万一用得上”但实际上八辈子都用不上的东西扔掉一样，轻装上阵。
这年头，前端项目越来越大，依赖的第三方库也越来越多，很多库都自带一大堆你根本用不上的功能。如果不做Tree Shaking，打包出来的文件体积会非常庞大，加载速度慢得让人怀疑人生。
第二幕：Tree Shaking的原理，有点像侦探破案
Tree Shaking的核心在于静态分析。它会在构建时分析你的代码，找出哪些导出的变量、函数、类等没有被用到。注意，是“静态分析”，这意味着它不会真正运行你的代码，而是通过分析代码的结构来判断。
举个例子：
// module.js
export function add(a, b) {
return a + b;
}
export function subtract(a, b) {
return a - b;
}// main.js
import { add } from './module.js';
console.log(add(1, 2));在这个例子中，subtract函数虽然被导出了，但在main.js中并没有被使用。Tree Shaking就能识别出这一点，在打包的时候把它移除掉。
第三幕：Tree Shaking的局限性，不是万能的！
虽然Tree Shaking听起来很美好，但它并不是万能的。它有很多局限性，稍不注意，就会导致Tree Shaking失效。
-
动态导入（Dynamic Imports）：
Tree Shaking依赖于静态分析，而动态导入（
import()）是在运行时才确定要加载哪些模块，这使得静态分析变得困难。虽然现在的构建工具（如Webpack）对动态导入也有一定的Tree Shaking支持，但效果通常不如静态导入。// 动态导入 import(`./module_${someVariable}.js`).then(module => { module.doSomething(); });因为
someVariable的值是在运行时确定的，构建工具无法确定具体要导入哪个模块，也就无法进行Tree Shaking。 -
CommonJS 模块：
Tree Shaking对ES模块（
import/export）支持得更好，因为ES模块的静态分析更容易。CommonJS模块（require/module.exports）由于其动态性，Tree Shaking的效果通常较差。// CommonJS const module = require('./module.js'); module.add(1, 2);CommonJS的
require语句是在运行时执行的，构建工具无法确定module对象具体包含了哪些属性，也就无法进行精确的Tree Shaking。 -
副作用（Side Effects）：
这是Tree Shaking最大的敌人。副作用指的是函数或表达式除了返回值之外，还会对外部环境产生影响，比如修改全局变量、修改DOM、发送HTTP请求等。
// 带有副作用的模块 window.counter = 0; export function increment() { window.counter++; return window.counter; }即使
increment函数没有被直接使用，但由于它会修改全局变量window.counter，构建工具通常会保守地认为它可能是有用的，而不会将其移除。 -
代码风格问题：
一些不良的代码风格也可能导致Tree Shaking失效。例如，直接修改导入的变量：
// module.js export let counter = 0; // main.js import { counter } from './module.js'; counter++; // 危险！ console.log(counter);这种做法会导致构建工具难以追踪变量的使用情况，从而影响Tree Shaking的效果。
第四幕：sideEffects配置，控制副作用！
sideEffects是package.json中的一个字段，用于告诉构建工具哪些文件或模块具有副作用。它可以帮助构建工具更准确地判断哪些代码可以安全地移除。
sideEffects可以是一个布尔值或一个数组。
-
sideEffects: false：表示整个项目中的所有文件都没有副作用。这通常只适用于纯函数库或工具库。
-
sideEffects: ["./src/styles.css", "./src/global.js"]：表示只有指定的这些文件具有副作用，其他文件都可以安全地进行Tree Shaking。
第五幕：sideEffects的深度优化，精益求精！
仅仅设置sideEffects为false或指定几个副作用文件是不够的，我们需要更深入地优化，才能充分发挥Tree Shaking的威力。
-
精确指定副作用文件：
尽量避免将整个目录标记为具有副作用，而应该精确到具体的文件。例如，如果只有
src/components/Button/style.css具有副作用，就不要将整个src/components/Button目录都标记为具有副作用。 -
拆分副作用代码：
如果一个模块中既包含有副作用的代码，又包含纯函数，可以将它们拆分成不同的模块。例如：
// utils.js (包含纯函数) export function add(a, b) { return a + b; } // effects.js (包含副作用) import { add } from './utils.js'; window.counter = 0; export function increment() { window.counter = add(window.counter, 1); // 使用纯函数 return window.counter; }然后在
package.json中指定effects.js具有副作用：{ "name": "my-library", "version": "1.0.0", "sideEffects": ["./effects.js"] }这样，即使
increment函数没有被使用，effects.js也不会被Tree Shaking掉，但utils.js中的add函数仍然可以被Tree Shaking。 -
使用纯函数：
尽量使用纯函数来编写代码，避免副作用。纯函数的特点是：
- 相同的输入始终产生相同的输出。
- 没有副作用。
纯函数更容易进行Tree Shaking，并且更容易测试和维护。
-
利用ES模块的静态分析能力：
尽量使用ES模块（
import/export）来组织代码，而不是CommonJS模块（require/module.exports）。ES模块的静态分析能力更强，更有利于Tree Shaking。 -
构建工具的配置：
不同的构建工具对Tree Shaking的实现方式略有不同，需要根据具体的构建工具进行配置。例如，在Webpack中，需要确保
mode设置为production，并且使用了支持Tree Shaking的模块打包器（如TerserWebpackPlugin）。// webpack.config.js const TerserPlugin = require('terser-webpack-plugin'); module.exports = { mode: 'production', optimization: { minimizer: [new TerserPlugin()], usedExports: true, // 启用Tree Shaking }, }; -
特殊情况处理 – CSS Modules:
如果你使用CSS Modules，通常CSS本身没有副作用（除非你有一些很奇怪的全局样式修改逻辑）。 但是，CSS Modules的导入通常会影响组件的渲染，因此在某些情况下，构建工具可能无法正确地进行Tree Shaking。 确保你的构建配置正确处理了CSS Modules，并且使用了合适的CSS提取插件（例如
mini-css-extract-plugin），以便将CSS提取到单独的文件中，避免影响JS的Tree Shaking。// webpack.config.js const MiniCssExtractPlugin = require("mini-css-extract-plugin"); module.exports = { module: { rules: [ { test: /.module.css$/, // 匹配CSS Modules文件 use: [ MiniCssExtractPlugin.loader, // 提取CSS到单独文件 { loader: "css-loader", options: { modules: true, // 启用CSS Modules }, }, ], }, ], }, plugins: [new MiniCssExtractPlugin()], }; -
代码审查和测试:
即使你做了所有的配置和优化，也需要进行代码审查和测试，以确保Tree Shaking真正生效。 你可以使用构建工具的分析功能（例如Webpack的
webpack-bundle-analyzer）来查看最终打包结果，确认没有不必要的代码被包含进来。 编写单元测试，特别是针对库的公共API，可以帮助你发现潜在的Tree Shaking问题。
第六幕：案例分析，实战演练！
假设我们有一个名为my-library的库，目录结构如下：
my-library/
├── package.json
├── src/
│ ├── index.js
│ ├── utils.js
│ ├── components/
│ │ ├── Button.js
│ │ ├── Button.module.css
│ │ └── Input.js
│ └── global.jsindex.js：库的入口文件，导出所有公共API。utils.js：包含一些纯函数。components/Button.js：一个按钮组件。components/Button.module.css：按钮组件的样式文件（CSS Modules）。components/Input.js：一个输入框组件，没有被使用。global.js：包含一些全局初始化代码，具有副作用。
package.json的内容如下：
{
"name": "my-library",
"version": "1.0.0",
"main": "src/index.js",
"sideEffects": [
"./src/global.js",
"./src/components/Button.module.css"
],
"scripts": {
"build": "webpack"
},
"devDependencies": {
"css-loader": "^6.8.1",
"mini-css-extract-plugin": "^2.7.6",
"terser-webpack-plugin": "^5.3.9",
"webpack": "^5.88.2",
"webpack-cli": "^5.1.4"
}
}webpack.config.js的内容如下：
const path = require('path');
const TerserPlugin = require('terser-webpack-plugin');
const MiniCssExtractPlugin = require("mini-css-extract-plugin");
module.exports = {
mode: 'production',
entry: './src/index.js',
output: {
path: path.resolve(__dirname, 'dist'),
filename: 'my-library.js',
library: 'MyLibrary',
libraryTarget: 'umd',
},
module: {
rules: [
{
test: /.module.css$/,
use: [
MiniCssExtractPlugin.loader,
{
loader: "css-loader",
options: {
modules: true,
},
},
],
},
],
},
optimization: {
minimizer: [new TerserPlugin()],
usedExports: true,
},
plugins: [new MiniCssExtractPlugin()],
};在这个案例中，我们做了以下优化：
- 精确指定了
global.js和Button.module.css具有副作用。 - 使用了CSS Modules来管理样式，避免全局样式污染。
- 使用了Webpack和TerserWebpackPlugin来进行Tree Shaking。
最终，Input.js组件由于没有被使用，会被Tree Shaking掉。
第七幕：总结，Tree Shaking是一门艺术！
Tree Shaking是一门艺术，它需要我们深入理解其原理，了解其局限性，并结合sideEffects配置进行深度优化。只有这样，才能真正发挥Tree Shaking的威力，减小打包体积，提升应用性能。
记住，代码质量是Tree Shaking的基础。编写高质量的代码，尽量避免副作用，使用纯函数，才能让Tree Shaking更加有效。
最后，送给大家一句忠告：不要过度迷恋Tree Shaking，它只是优化手段之一。更重要的是编写清晰、可维护的代码。
感谢大家的观看，希望今天的讲座对大家有所帮助！