前端模块化进化史：从全局 function 到 ES Modules

目前，前端开发已经离不开由 CommonJS、ES Modules 和 Webpack 构建的模块化开发环境。无论是 JavaScript、CSS、图片还是其他资源，都可以作为一个模块来处理。那么，模块化究竟是如何发展到今天的呢？

全局函数模式

最初的前端模块化尝试是通过 全局函数来实现的。例如，在一个 util.js 文件中定义了一个变量 count 和一个工具函数 formatNumberWithCommas，用于将数字转换成带千分位分隔符的字符串：

var count = 1;
function formatNumberWithCommas(number) {
  if (typeof number !== "number") {
    throw new TypeError("Input must be a number.");
  }
  return number.toLocaleString("en-US");
}

在 index.html 文件中通过 <script> 标签将 util.js 资源引入：

<script src="../src/util.js"></script>

此时 util.js 文件内的变量和函数将挂载到全局对象 window 上。

在浏览器的 Console 控制台上直接输入 window.formatNumberWithCommas 就可以访问该函数。

然而，这种方式存在一个问题：不同的 JS 文件间一旦存在相同的变量或函数名就会互相覆盖，从而导致某些变量或函数不可用。

全局命名空间

为了避免全局函数命名冲突的问题，进一步采用了通过对象封装模块的方式。例如，在 util.js 文件中定义了一个全局对象 __Util：

window.__Util = {
  count: 1,
  formatNumberWithCommas(number) {
    if (typeof number !== "number") {
      throw new TypeError("Input must be a number.");
    }
    return number.toLocaleString("en-US");
  },
};

通过为全局对象定义一个较复杂的名称，可以减少命名冲突的风险。然而，这种方式下对象内的属性很容易被外部修改。例如，将 window.__Util 赋值给变量 d，再修改 d 中的 count 时，window.__Util 中的 count 属性也会被修改。

IIFE 自执行函数

为了解决模块内的变量容易被外界随意修改的问题，通过 IIFE（立即执行函数表达式）创建闭包来实现模块化。例如：

(function () {
  var count = 1;
  function formatNumberWithCommas(number) {
    if (typeof number !== "number") {
      throw new TypeError("Input must be a number.");
    }
    return number.toLocaleString("en-US");
  }
  function getCount() {
    return count;
  }
  function setCount(num) {
    count = num;
  }
  window.__Util = {
    formatNumberWithCommas,
    getCount,
    setCount,
  };
})();

此时我们不直接将 count 变量导出，而是通过 getCount 获取 count 的值，通过 setCount 修改 count 的值。

这种方式使得模块内的变量不能被外界随意修改。然而，这种模式下存在的问题是，如果存在多个模块，且它们之间有依赖关系，就无法很好地支持。

IIFE 自定义依赖

为了解决 IIFE 无法关联模块的问题，可以通过在 IIFE 中传入参数来将各模块关联起来。例如，新增一个 verify.js 文件，并在 index.html 中引入：

(function (global) {
  function isNumber(num) {
    return typeof num === "number";
  }
  global.__Verify = {
    isNumber,
  };
})(window);

同时改造 util.js 文件，接收 verify.js 文件中绑定到全局的 __Verify 属性，并调用 __Verify 中的 isNumber 方法：

(function (global, verifyModule) {
  var count = 1;
  function formatNumberWithCommas(number) {
    if (!verifyModule.isNumber(number)) {
      throw new TypeError("Input must be a number.");
    }
    return number.toLocaleString("en-US");
  }
  function getCount() {
    return count;
  }
  function setCount(num) {
    count = num;
  }
  global.__Util = {
    formatNumberWithCommas,
    getCount,
    setCount,
  };
})(window, window.__Verify);

尽管这种方式能够在一定程度上支持模块化，但如果模块过多，特别是在现代项目中，模块数量动辄几十上百个，这种方式就显得力不从心，而且代码的可读性和维护性也会受到影响。

commonjs

以上提到的方法都是通过简单的代码实现模块化功能，但随着 CommonJS 的出现，一套正式的模块化规范开始形成。CommonJS 使用 module.exports 导出模块，并通过 require 加载其他模块，从而实现模块间的交互。

让我们对之前的 verify.js 和 util.js 文件进行改造以适应 CommonJS 规范：

// verify.js
function isNumber(num) {
  return typeof num === "number";
}
module.exports = {
  isNumber,
};

// util.js
const { isNumber } = require("./verify");
function formatNumberWithCommas(number) {
  if (!isNumber(number)) {
    throw new TypeError("Input must be a number.");
  }
  return number.toLocaleString("en-US");
}
console.log("formatNumberWithCommas", formatNumberWithCommas(123456));

通过命令行工具执行 node ./src/util.js，可以看到 console.log 输出的结果。

CommonJS 规范是为服务器端设计的，它假定所有的模块加载都是同步的。然而，在客户端环境中，由于网络延迟，这种方式可能会导致用户界面的阻塞，从而影响用户体验。

AMD

AMD（Asynchronous Module Definition）规范则是为了解决浏览器端模块加载的异步需求而设计的。AMD 规范使用 define 来定义模块，并且通过 return 导出模块内容，同时使用 require 来加载其他模块。

以下是 verify.js 和 util.js 改造后的 AMD 规范代码：

// verify.js
define(function () {
  function isNumber(num) {
    return typeof num === "number";
  }
  return {
    isNumber: isNumber,
  };
});

// util.js
define(['verify'], function(verify) {
  function formatNumberWithCommas(number) {
    if (!verify.isNumber(number)) {
      throw new TypeError("Input must be a number.");
    }
    return number.toLocaleString("en-US");
  }
  return {
    formatNumberWithCommas: formatNumberWithCommas
  };
});

此外，定义一个 index.js 文件来使用这些模块：

define(function (require) {
  var util = require("util");
  console.log("formatNumberWithCommas", util.formatNumberWithCommas(123456));
});

在 HTML 页面中，可以通过 RequireJS 来解析 AMD 规范的代码，并通过 HTML 属性 data-main 指定入口文件：

 <script data-main="../src/index.js" src="https://cdn.bootcdn.net/ajax/libs/require.js/2.3.6/require.js"></script>

打开 HTML 页面时，可以在浏览器控制台中看到输出结果。

CMD

CMD（Common Module Definition）规范在 AMD 的基础上进行了改进，尤其是在异步加载和延迟执行方面。CMD 规范同样使用 define 来定义模块，但导出模块时使用的是 exports。

下面是 verify.js 和 util.js 按照 CMD 规范的代码示例：

// verify.js
define(function (require, exports, module) {
  function isNumber(num) {
    return typeof num === "number";
  }
  exports.isNumber = isNumber;
});

// util.js
define(function (require, exports, module) {
  var verify = require("verify");
  function formatNumberWithCommas(number) {
    if (!verify.isNumber(number)) {
      throw new TypeError("Input must be a number.");
    }
    return number.toLocaleString("en-US");
  }
  exports.formatNumberWithCommas = formatNumberWithCommas;
});

为了在浏览器中运行 CMD 规范的代码，可以使用 Sea.js。在 HTML 文件中添加以下代码：

<script src="https://cdn.bootcdn.net/ajax/libs/seajs/3.0.3/sea.js"></script>
<script>
  seajs.config({
    alias: {
      verify: "../src/verify",
      util: "../src/util",
    },
  });
  seajs.use(["util"], function (util) {
    console.log(
      "formatNumberWithCommas",
      util.formatNumberWithCommas(123456)
    );
  });
</script>

ES Modules

相比之下，ES Modules（ESM） 作为 ECMAScript 标准的一部分，不仅提供了更为简洁的语法用于模块的导入和导出，还具备动态加载的能力，提高了模块间协作的效率与灵活性。

下面是如何用 ESM 来重写 verify.js 和 util.js：

// verify.js
export function isNumber(num) {
  return typeof num === "number";
}

// util.js
import { isNumber } from "./verify.js";
export function formatNumberWithCommas(number) {
  if (!isNumber(number)) {
    throw new TypeError("Input must be a number.");
  }
  return number.toLocaleString("en-US");
}

为了测试 formatNumberWithCommas 函数，我们定义一个 index.js 文件：

// index.js
import { formatNumberWithCommas } from "./util.js";
console.log("formatNumberWithCommas", formatNumberWithCommas(123456));

在 index.html 文件中引入 index.js，浏览器本身就支持 ESModule，只需要将 type 需要定义成 module。

  <script type="module" src="../src/index.js"></script>

尽管现代浏览器原生支持 ES Modules，但浏览器自身并不具备有效的模块管理机制。这意味着，每一个模块都会作为一个独立的 JS 资源文件加载，这不仅导致资源文件过于分散，而且每次加载模块都会产生新的服务器请求，从而增加了加载时间，降低了性能，这在大型项目中尤其明显。

为了解决这些问题，开发者社区引入了 npm 和 webpack 这样的工具。npm 作为最流行的 JavaScript 包管理器之一，能够有效地管理和组织模块依赖关系，确保项目的模块化组件能够被正确地安装和更新。另一方面，webpack 则是一个模块打包工具，它可以将多个模块和它们的依赖合并成单个文件或一组优化过的文件，同时还能进行压缩等优化操作，以减少最终输出文件的大小，提高加载速度和应用的整体性能。

关于 npm 和 webpack 的相关内容，大家可以查看我其他的博客，持续更新中~