CommonJS 是如何导致打包后体积增大的？

 

原文链接：https://web.dev/commonjs-larger-bundles

今天的何导文章，将介绍什么是致打增 CommonJS，以及它为什么会导致我们打包后的包后文件体积增大。

什么是体积 CommonJS?

CommonJS 是 2009 年发布的 JavaScript模块化的一项标准，最初它只打算在浏览器之外的何导场景使用，主要用于服务器端的致打增应用程序。

你可以使用 CommonJS 来定义模块，包后并从中导出部分模块。体积例如，何导下面的致打增代码定义了一个模块，该模块导出了五个函数：add、包后 subtract、体积 multiply、何导 divide、致打增max:

// utils.js const {  maxBy } = require(lodash-es); const fns = {    add: (a,包后 b) => a + b,   subtract: (a, b) => a - b,   multiply: (a, b) => a * b,   divide: (a, b) => a / b,   max: arr => maxBy(arr) }; Object.keys(fns).forEach(fnName => module.exports[fnName] = fns[fnName]); 

其他模块可以导入这个模块的部分函数。

// index.js const {  add } = require(‘./utils); console.log(add(1, 2)); 

通过 node 运行 index.js ，会在控制台输出数字 3。

在 2010 年，由于浏览器缺乏标准化的模块化能力，CommonJS 成了当时 JavaScript 客户端较为流行的模块化标准。

CommonJS 如何影响包体?

服务端的高防服务器 JavaScript 程序对代码体积并不像浏览器中那么敏感，这就是为什么在设计 CommonJS 的时候，并没有考虑减少生产包大小的原因。同时，研表究明 JavaScript 代码的体积依然是影响页面加载速度的一个重要因素。

JavaScript 的打包工具(webpack、terser)会进行许多优化以减小最后生成的包体大小。他们在构建时，会分析你的代码，尽可能的删除不会使用的部分。例如，上面的代码中，最终生成的包应该只包含 add 函数，因为这是 index.js 唯一从 utils.js 中导入的部分。

下面我们使用如下 webpack 配置对应用进行打包：

const path = require(path); module.exports = {    entry: index.js,   output: {      filename: out.js,     path: path.resolve(__dirname, dist),   },   mode: production, }; 

我们需要将 webpack 的 mode 指定为 production，并且将 index.js 作为入口。运行 webpack 后，香港云服务器会输出一个文件：dist/out.js，可以通过如下方式统计它的大小：

$ cd dist && ls -lah 625K Apr 13 13:04 out.js 

打包后的文件高达 625 KB。如果看下 out.js 文件，会发现 utils.js 导入 lodash 的所有模块都打包到了输出的文件中，尽管我们在 index.js 并没有使用到 lodash 的任何方法，但是这给我们的包体带来了巨大的影响。

现在我们将代码的模块化方案改为 ESM，utils.js 部分的代码如下：

export const add = (a, b) => a + b; export const subtract = (a, b) => a - b; export const multiply = (a, b) => a * b; export const divide = (a, b) => a / b; import {  maxBy } from lodash-es; export const max = arr => maxBy(arr); 

index.js 也改为 ESM 的方式从 utils.js 导入模块：

import {  add } from ./utils; console.log(add(1, 2)); 

使用相同的 webpack 配置，构建完毕之后，我们打开 out.js ，仅有 40 字节，输出如下：

(()=>{ "use strict";console.log(1+2)})(); 

值得注意的是，最终的输出并没有包含 utils.js 的任何代码，而且 lodash 也消失了。而且 terser(webpack 使用的压缩工具)直接将 add 函数内联到了 console.log 内部。

有的云服务器小朋友可能就会问了(此处采用了李永乐语法)，为什么使用 CommonJS 会导致输出的文件大了 16,000 倍?当然，这只是用来展示 CommonJS 与 ESM 差异的案例，实际上并不会出现这么大的差异，但是使用 CommonJS 肯定会导致打包后的体积更大。

一般情况下，CommonJS 模块的体积更加难优化，因为它比 ES 模块更加的动态化。为了确保构建工具以及压缩工具能成功优化代码，请避免使用 CommonJS 模块。

当然，如果你只在 utils.js 采用了 ESM 的模块化方案，而 index.js 还是维持 CommonJS，则包体依旧会受到影响。

为什么 CommonJS 会使包体更大?

要回答这个问题，我们需要研究 webpack 的 ModuleConcatenationPlugin 的行为，并且看看它是如何进行静态分析的。该插件将所有的模块都放入一个闭包内，这会让你的代码在浏览器中更快的执行。我们来看看下面的代码：

// utils.js export const add = (a, b) => a + b; export const subtract = (a, b) => a - b;  // index.js import {  add } from ‘./utils; const subtract = (a, b) => a - b; console.log(add(1, 2)); 

我们有一个新的 ESM 模块(utils.js)，将其导入 index.js 中，我们还重新定义一个 subtract 函数。接下来使用之前的 webpack 配置来构建项目，但是这次，我把禁用压缩配置。

const path = require(path); module.exports = {    entry: index.js,   output: {      filename: out.js,     path: path.resolve(__dirname, dist),   }, + optimization: {  +   minimize: false + },   mode: production, }; 

输出的 out.js 如下：

/