为何 CommonJS 会使你的程序包变大

做者：Minko Gechev

翻译：疯狂的技术宅

原文：https://web.dev/commonjs-larg...

未经容许严禁转载

在本文中，咱们将研究什么是 CommonJS，以及为何它会使你的 JavaScript 包变得那么大。

什么是 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 模块，则打包后的大小也会受到影响。

为何 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 模块语法。

---

本文首发微信公众号：前端先锋

欢迎扫描二维码关注公众号，天天都给你推送新鲜的前端技术文章

欢迎继续阅读本专栏其它高赞文章：

• 深刻理解Shadow DOM v1
• 一步步教你用 WebVR 实现虚拟现实游戏
• 13个帮你提升开发效率的现代CSS框架
• 快速上手BootstrapVue
• JavaScript引擎是如何工做的？从调用栈到Promise你须要知道的一切
• WebSocket实战：在 Node 和 React 之间进行实时通讯
• 关于 Git 的 20 个面试题
• 深刻解析 Node.js 的 console.log
• Node.js 到底是什么？
• 30分钟用Node.js构建一个API服务器
• Javascript的对象拷贝
• 程序员30岁前月薪达不到30K，该何去何从
• 14个最好的 JavaScript 数据可视化库
• 8 个给前端的顶级 VS Code 扩展插件
• Node.js 多线程彻底指南
• 把HTML转成PDF的4个方案及实现

---

• 更多文章...