为什么 CommonJS 会使你的程序包变大
什么是 Commonjs？
CommonJS 是 2009 年的标准，为 JavaScript 模块建立了约定。它最初打算在 Web 浏览器之外使用，主要用于服务器端。
使用 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 函数，因为这是你从utils.js 中导入到在 index.js 中的的唯一符号。
让我们使用以下 webpack 配置来构建程序：
const path = require('path');
module.exports = {
entry: 'index.js',
output: {
filename: 'out.js',
path: path.resolve(__dirname, 'dist'),
},
mode: 'production',
};在这里，我们指定要使用生产模式优化，并把 index.js 作为进入点。在调用 webpack之后，如果我们查看输出 的大小，将会看到类似以下的内容：
$ cd dist && ls -lah
625K Apr 13 13:04 out.js请注意，输出的包为 625 KB。如果看一下输出，我们将从 utils.js 中找到所有函数，再从 lodash 中找到很多模块。尽管我们没有在 index.js 中使用 lodash，但它是输出的一部分，这给我们的生产环境代码增加了很多额外的东西。
现在，让我们把模块格式改为 ECMAScript 2015 的格式，然后再试。这次 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);然后用 ES2015 模块语法从 utils.js 导入 index.js：
import { add } from './utils';
console.log(add(1, 2));使用相同的 webpack 配置，构建我们的程序并查看输出文件， 现在为 40 字节，并带有以下输出内容：
(()=>{"use strict";console.log(1+2)})();注意，最终的包中不含我们没有用到的来自 utils.js 的任何函数，也没有来自 lodash 的痕迹！更进一步，terser（webpack 使用的 JavaScript 压缩程序）在 console.log 中内联了 add 功能。
你可能会问：为什么使用 CommonJS 会导致输出的包大了几乎 16,000 倍？当然这是一个例子而已，实际上大小差异可能没那么大，但是 CommonJS 很有可能大大的增加了你生产构建的大小。
一般 CommonJS 模块很难优化，因为它们比 ES 模块要动态得多。为确保打包和压缩程序能够成功优化应用程序，应该避免依赖 CommonJS 模块，并在整个程序中使用 ES2015 模块语法。
要注意，即使你在 index.js 中用了 ES2015 规则，但是如果你用的模块是 CommonJS 模块，则打包后的大小也会受到影响。
广州设计公司https://www.houdianzi.com 我的007办公资源网站https://www.wode007.com
为什么 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));上面有一个 ES2015 模块，我们将其导入到 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',
};让我们看一下产生的输出：
/******/ (() => { // webpackBootstrap
/******/ "use strict";
// CONCATENATED MODULE: ./utils.js**
const add = (a, b) => a + b;
const subtract = (a, b) => a - b;
// CONCATENATED MODULE: ./index.js**
const index_subtract = (a, b) => a - b;**
console.log(add(1, 2));**
/******/ })();在上面的输出中，所有函数都在同一个命名空间内。为了防止冲突，webpack 将 index.js 中的 subtract 函数重命名为 index_subtract。
如果压缩程序处理上面的源代码，它将会：
- 删除未使用的 subtract 和 index_subtract 函数
- 删除所有注释和多余的空格
- 在 console.log 调用中内联 add 函数的主体
开发人员经常将这种把删除未使用的 imports 视为 tree-shaking。因为 webpack 能够（在构建时）静态地知道我们正在从 utils.js 中导入及导出了哪些符号，所以只能进行 tree-shaking 。
默认情况下，ES 模块会启用此行为，因为与 CommonJS 相比，它们可以静态分析。
让我们看一看完全相同的例子，但是这次将 utils.js 改为使用 CommonJS 而不是 ES 模块：
// 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]);这个小更新将显著改变输出。由于代码太长，我只分享其中的一小部分：
...
(() => {
"use strict";
/* harmony import */ var _utils__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__(288);
const subtract = (a, b) => a - b;
console.log((0,_utils__WEBPACK_IMPORTED_MODULE_0__/* .add */ .IH)(1, 2));
})();请注意，最终的包中会含有一些 webpack “运行时”：一些注入的代码，负责从打包的模块中导入和导出函数。这次，我们没有把来自 utils.js 和 index.js 的所有符号放在同一个命名空间下，而是在运行时动态地使用了__webpack_require__ 的 add 函数。
这是必需的，因为我们用 CommonJS 可以从任意表达式中获取导出名称。例如下面的代码是绝对有效的构造：
module.exports[localStorage.getItem(Math.random())] = () => { … };打包器无法在构建时知道导出的符号的名称，因为这需要用户浏览器的上下文中的仅在运行时可用的信息。
这样，压缩器无法从其依赖项中了解 index.js 的确切用途，因此它无法将其 tree-shaking 掉。我们还将观察到第三方模块的行为完全相同。 如果从 node_modules 导入 CommonJS 模块，你的构建工具链将会无法正确的优化它。
使用 CommonJS tree-shaking
由于 CommonJS 模块是动态定义的，因此分析它们要困难得多。例如与作为表达式的 CommonJS 相比，ES 模块中的导入位置始终是字符串。
在某些情况下，如果你使用的库遵循有关使用 CommonJS 的特定约定，则可以在构建时使用第三方 webpack plugin。尽管此插件增加了对 tree-shaking 的支持，但并未涵盖依赖项可以使用 CommonJS 的所有方式。这就意味着你无法获得与 ES 模块相同的保证。另外除了默认的 webpack 行为外，它还会在构建过程中增加额外的成本。
总结
为确保捆绑程序可以成功优化你的程序，请避免依赖 CommonJS 模块，并在整个程序中使用 ES2015 模块语法。
