不要再依赖 CommonJS 了

CommonJS 是 2009 年的标准，为 JavaScript 模块建立了约定。它最初打算在 Web 浏览器之外的场景中使用，主要用于服务端应用程序。

使用 CommonJS，你可以定义模块，从中导出功能，并将它们导入其他模块中。例如，下面的代码片段定义了一个模块，其导出五个函数：add，subtract，multiply，divide 和 max：

// utils.jsconst { 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.jsconst { add } = require(‘./utils');console.log(add(1, 2));

使用 node 调用 index.js 将在控制台中输出数字 3。

由于 2010 年代初期浏览器中缺乏标准化的模块系统，CommonJS 也成为了 JavaScript 客户端库的流行模块格式。

2CommonJS 如何影响最终的打包大小？

服务端 JavaScript 应用程序的大小并不像浏览器中那样重要，所以 CommonJS 并没有在设计时考虑到包大小的控制。与此同时，有分析表明 JavaScript 的包体积仍然是拖慢浏览器应用的主要因素之一。

JavaScript 打包器和压缩器（minifier），例如 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 -lah625K Apr 13 13:04 out.js

请注意，这个包的大小为 625KB。看一下输出，我们将找到来自 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);

并且 index.js 将使用 ES2015 模块语法从 utils.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 也很有可能给你的生产构建增添了很大的负担。

请注意，即使你在 index.js 中使用了 ES2015，但如果你使用的模块是 CommonJS，应用程序的打包大小也会受到影响。

3为什么 CommonJS 会让应用程序体积更大？

为了回答这个问题，我们将研究 webpack 中 ModuleConcatenationPlugin 的行为，然后讨论静态可分析性。这个插件将所有模块合并为一个闭包，并能让你的代码在浏览器中执行得更快。我们来看一个例子：

// utils.jsexport const add = (a, b) => a + b;export const subtract = (a, b) => a - b;

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

如上所示，我们有一个 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 函数的主体

开发人员通常将这种移除未使用的导入的操作称为摇树优化（tree-shaking）。因为 webpack 能够静态地（在构建时）了解我们从 utils.js 导入及导出的符号，所以它才能实现摇树优化。

ES 模块默认启用此行为，因为与 CommonJS 相比，它们更容易进行静态分析。

我们来看完全相同的示例，但是这次将 utils.js 更改为使用 CommonJS 模块：

// utils.jsconst { 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));})();