爲何 CommonJS 會使你的程序包變大

時間 2020-05-19

標籤爲何 commonjs 程序變大简体版

原文原文鏈接

做者：Minko Gechev
翻譯：瘋狂的技術宅javascript

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

未經容許嚴禁轉載java

在本文中，咱們將研究什麼是 CommonJS，以及爲何它會使你的 JavaScript 包變得那麼大。node

什麼是 CommonJS？

CommonJS 是 2009 年的標準，爲 JavaScript 模塊創建了約定。它最初打算在 Web 瀏覽器以外使用，主要用於服務器端。webpack

使用 CommonJS，你能夠定義模塊，從中導出功能，以及將其導入其餘模塊中。例如，下面的代碼段定義了一個模塊，該模塊導出五個功能： add、subtract、multiply、divide 和 max：git

// 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。github

因爲在 2010 年代初期，瀏覽器中缺少標準化的模塊系統，CommonJS 也成爲了 JavaScript 客戶端庫流行的模塊格式。web

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 行爲外，它還會在構建過程當中增長額外的成本。