黎明之前：模块化的漫漫征途

第 1 章：黎明之前：模块化的漫漫征途

蛮荒时代的序曲

那是一个我们今天几乎无法想象的年代。

2010年，如果你打开一个典型的电子商务网站——比如说，一个售卖电子产品的在线商城——你很可能会看到这样的代码。这不是来自某个古老的遗留系统，而是那个时代最正常不过的开发方式：

```html <!DOCTYPE html> <html> <head> <title>极客电子产品商城</title>

<!-- 核心依赖库 --> <script src="jquery-1.4.2.min.js"></script> <script src="jquery-ui-1.8.2.min.js"></script> <script src="prototype-1.6.1.min.js"></script>

<!-- 业务逻辑 --> <script src="utils.js"></script> <script src="constants.js"></script> <script src="cart.js"></script> <script src="product.js"></script> <script src="user.js"></script> <script src="checkout.js"></script>

<!-- 页面初始化 --> <script src="main.js"></script> </head> <body> <!-- 页面内容... --> </body> </html> ```

这段代码看起来如此平常，如此“正确”，以至于你可能不会意识到它背后隐藏着怎样的混乱。每一个`script`标签都像是一个小小的黑箱，它们被期望以某种神秘的顺序被加载，彼此之间通过一个巨大的、全局共享的命名空间进行交流。`jQuery`把自己挂载到`window.$`上，`prototype`把它的魔法散布到`Array.prototype`和`String.prototype`，而你的`cart.js`则直接使用`$`和`ProductManager`——假设这些全局变量已经被正确设置，假设它们的版本没有冲突，假设加载顺序没有出错。

assumption，assumption，assumption。整个前端开发建立在无数假设之上，而任何一个假设的破灭都可能导致整个应用的崩溃。

这就是JavaScript蛮荒时代的真实面貌。在那个年代，我们今天习以为常的模块化、依赖管理、构建工具这些概念几乎完全不存在。JavaScript被设计成一门简单的脚本语言，用来在网页上添加一些交互效果。它的设计者Brendan Eich甚至没有预料到这门语言会在十年后承担起构建复杂Web应用的重任——更没有预料到需要一种系统性的方法来组织这些代码。

然而，历史总是充满讽刺。正是JavaScript最初被轻视的“简单性”，反而成为了它最大的优势。它可以快速上手，可以直接运行在浏览器中，可以渐进式地增强网页体验。但当应用规模开始增长时，这些“简单性”的遗产开始反噬开发者。变量命名冲突、全局环境污染、代码依赖混乱、加载顺序敏感——这些问题如同幽灵一般缠绕着每一个试图用JavaScript构建复杂系统的开发者。

我们今天要讲述的故事，正是关于人类如何在这片蛮荒中建立秩序的史诗。而Webpack，正是这场秩序革命的产物。

蛮荒时代的众生相

要理解为什么模块化如此重要，我们首先需要理解蛮荒时代究竟有多混乱。让我带你穿越回那个年代，亲身体验一下当时开发者面临的困境。

想象你是一个前端团队的成员，正在开发一个中型Web应用。应用的规模不大不小——大约有两万行JavaScript代码分布在十几个文件中。你的团队有四个人，每个人负责不同的功能模块：用户系统、商品系统、购物车、订单处理、支付集成、数据分析埋点。

听起来职责分明，对吧？问题在于，当你们试图把这些代码整合到一起时，噩梦才刚刚开始。

第一个问题是全局命名空间的战争。 JavaScript的变量声明规则非常宽松，你不加`var`声明的变量会自动成为全局变量。在蛮荒时代，很多开发者养成了不好的习惯：他们直接在函数中使用`userId = response.userId`而不是`var userId = response.userId`。这些意外的全局变量会在意想不到的地方造成冲突。

你的团队成员小张在`user.js`中定义了一个全局函数`formatDate`，用来格式化日期。小李在`order.js`中也定义了一个同名的`formatDate`，但参数格式略有不同。在小李的机器上，他的测试通过了——因为他加载`order.js`时会覆盖掉小张的`formatDate`。但当用户真正使用系统时，`user.js`被后加载，它的`formatDate`覆盖了小李的实现，小李的订单日期格式瞬间变成了乱码。

这种问题在蛮荒时代是如此普遍，以至于出现了一个专门的术语来描述它：命名空间污染。开发者们开始想出各种方法来规避这个问题。最简单的方法是在每个变量前加上项目前缀：`geekStoreUserId`、`geekStoreCartTotal`——这让你的代码读起来像是在和一台话痨的机器人对话。更优雅一点的方法是创建一个全局的命名空间对象：

```javascript // 创建全局命名空间 var GeekStore = GeekStore || {};

// 将所有内容挂载到这个命名空间下 GeekStore.User = { currentUserId: null, getUserInfo: function() { /* ... */ } };

GeekStore.Cart = { items: [], addItem: function(item) { /* ... */ } }; ```

这看起来好多了，至少我们把相关的功能聚合在一起。但问题并没有根本解决：多个团队成员同时修改`GeekStore`对象时，冲突仍然可能发生；我们仍然需要手动管理加载顺序；如果某个模块依赖于另一个模块，我们只能通过注释和约定来确保正确的加载顺序。

第二个问题是依赖地狱。 让我们继续刚才的故事。你的团队决定引入一个第三方图表库来做销售数据分析。你们选择了当时流行的Flot——一个基于jQuery的图表插件。

```html <script src="jquery-1.4.2.min.js"></script> <script src="jquery-ui-1.8.2.min.js"></script> <script src="flot-0.6.min.js"></script> ```

看起来很简单，对吧？但Flot依赖jQuery，而jQuery本身又依赖浏览器环境。如果你在非浏览器环境（比如Node.js）中进行单元测试，事情就变得复杂了。更糟糕的是，不同版本的jQuery可能API不完全兼容——`jquery-ui-1.8.2`需要jQuery 1.4+，但如果另一个团队成员引入了`jquery-1.3.2`，整个系统可能崩溃。

而且，这只是单个依赖。想象一个真实的项目可能有几十个第三方库，每个库又有自己的依赖，形成了一张复杂的依赖网。这张网没有任何工具来管理它，开发者只能手动追踪、手动解决、手动确保加载顺序。当两个库依赖同一个库的不同版本时——这是常有的事——你只有一个选择：选择一个版本，然后在另一个库的源码中寻找兼容性问题，或者干脆放弃其中一个库。

第三个问题是静态分析的不可能性。 在蛮荒时代，由于所有变量都在全局作用域中流动，IDE和静态分析工具几乎无法理解代码的结构。你写了一个`getUserById`函数，但IDE不知道这个函数在哪里定义，不知道它的参数类型，不知道它的返回值，更不知道有哪些代码在调用它。重构变成了一种赌博式的冒险——你改了一处代码，不知道有多少地方会因此崩溃。

更糟糕的是，当你试图优化性能时，你发现无法分析哪些代码是真正被使用的，哪些是死代码。全局作用域让所有代码都是“活的”，即使它们从未被执行过。你只能小心翼翼地保留每一行代码，因为害怕移除它们会导致某些未知的依赖断裂。

第四个问题是测试的困难。 如何测试一个依赖于全局状态的函数？`cart.js`中的`addToCart`函数直接访问`GeekStore.User.currentUserId`来判断用户是否登录。在测试中，你首先需要确保`GeekStore.User.currentUserId`被正确设置，然后才能测试`addToCart`的行为。当你的测试需要模拟不同的用户状态时，你必须在每个测试用例之前手动设置这些全局状态。这种脆弱的测试结构让你的测试套件变得极其难以维护。

蛮荒时代的这些问题，像一座座大山横亘在开发者面前。它们不是无解的——聪明的开发者们开始尝试各种方法来解决这些困境。但每种方法都有其局限性，直到有一天，一个来自服务器端编程世界的概念被引入到JavaScript中，为整个行业指明了方向。

这个概念，就是模块。

服务器端的启示：CommonJS的诞生

2009年，JavaScript正在经历一场静悄悄的革命。Google Chrome的V8引擎让JavaScript的执行速度有了质的飞跃，Node.js的出现更是将JavaScript推向了服务器端。开发者们突然意识到，JavaScript不仅仅是一门浏览器脚本语言，它可以用来构建真正的服务器端应用。

然而，当开发者们开始在Node.js中编写大规模应用时，他们立刻遇到了与浏览器端相同的问题：如何组织代码？如何管理依赖？如何避免全局污染？

与浏览器端不同的是，服务器端JavaScript社区更加积极地寻求解决方案。当时的服务器端编程语言已经有了成熟的模块系统：Python有`import`语句，Ruby有`require`，Java有`import`包，PHP有`include`和`require`。Node.js需要一个类似的东西。

2009年，一个叫做Kevin Dangoor的人发起了个项目。他在Mozilla工作，和很多开发者一样，对JavaScript的混乱状况感到沮丧。他创建了一个邮件列表，邀请志同道合的人讨论JavaScript模块系统的问题。这个项目最初叫做ServerJS——一个专注于服务器端JavaScript模块系统的社区。

在邮件列表的讨论中，一个清晰的愿景逐渐形成：JavaScript需要一个标准化的模块定义格式，让代码可以在不同的环境（浏览器、服务器、桌面应用）中共享。这个愿景最终演变成了CommonJS规范。

CommonJS的核心思想非常简单：每个文件就是一个模块，模块有自己的作用域，模块通过导出接口来暴露其API，通过require来引入其他模块。 这与服务器端语言的模块系统非常相似——Python的开发者会觉得很熟悉，因为它几乎就是Python import系统的JavaScript版本。

```javascript // user.js - 一个CommonJS模块 // 模块私有的变量和函数 var _cache = {}; var _defaultTimeout = 5000;

function _fetchFromServer(userId) { // 私有实现细节 return fetch('/api/user/' + userId); }

// 导出公开API module.exports = { getUserById: async function(userId) { if (_cache[userId]) { return _cache[userId]; } const user = await _fetchFromServer(userId); _cache[userId] = user; return user; },

updateUser: async function(userId, data) { const user = await this.getUserById(userId); Object.assign(user, data); return fetch('/api/user/' + userId, { method: 'PUT', body: JSON.stringify(user) }); } }; ```

```javascript // cart.js - 依赖user模块 var userModule = require('./user');

// 使用user模块的功能 async function addToCart(productId, quantity) { var user = await userModule.getUserById(geekStore.currentUserId);

if (!user.cart) { user.cart = { items: [] }; }

user.cart.items.push({ productId, quantity }); await userModule.updateUser(user.id, { cart: user.cart });

return user.cart; }

module.exports = { addToCart }; ```

这个模式是如此优雅，如此自然，以至于它很快成为了Node.js的标准模块格式。Node.js从一开始就采用了CommonJS作为其模块系统的基础，这使得整个服务器端JavaScript生态能够快速建立起一个统一的模块仓库。

CommonJS的设计哲学可以概括为以下几点：

1. 文件即模块：每个JavaScript文件都是一个独立的模块，拥有自己的作用域。模块中定义的变量、函数、类默认都是私有的，不会污染全局命名空间。

2. 显式导出：模块通过`module.exports`或`exports`对象显式地导出其公共API。这种显式性使得接口定义清晰，开发者一眼就能看出模块提供了什么功能。

3. 显式导入：通过`require()`函数显式导入依赖的模块。这种显式性使得依赖关系一目了然，也为静态分析提供了可能。

4. 同步加载：模块在被require时会同步执行并返回导出对象。这简化了模块加载的逻辑，但也在浏览器环境中造成了性能问题（我们稍后会讨论这个问题）。

CommonJS在服务器端取得了巨大成功。npm（Node Package Manager）的诞生更是将这个成功推向了新的高度。npm允许开发者轻松地发布、分享和安装模块，形成了一个人类历史上最大的代码仓库之一。截至2023年，npm已经托管了超过200万个包，每周的下载量超过百亿次。

但是，当开发者试图将CommonJS应用到浏览器环境时，他们遇到了一个根本性的障碍：浏览器的异步性。

浏览器端的困境：AMD规范的分庭抗礼

CommonJS在Node.js中运行良好，因为Node.js是基于事件循环的服务器环境，文件的读取是同步的——当你调用`require('./user.js')`时，Node.js会阻塞当前线程，读取文件，执行代码，然后返回模块对象。这个过程是即时的，不需要考虑网络延迟。

但在浏览器环境中，一切都不同了。浏览器中的JavaScript运行在沙盒环境中，没有直接的文件系统访问权限。如果你想加载另一个JavaScript文件，你必须通过网络请求去获取它。网络请求是异步的——你需要发起请求，等待响应，然后才能执行返回的代码。

这意味着CommonJS的同步`require`在浏览器中是不可用的。如果浏览器也采用同步加载，每个模块都需要等待前一个模块的HTTP请求完成才能开始加载，这会导致灾难性的性能问题。加载10个模块就需要等待10个串行的网络往返时间，用户可能需要等待几十秒甚至几分钟才能看到页面。

AMD（Asynchronous Module Definition） 规范应运而生。AMD的核心思想是：既然浏览器必须异步加载代码，那就让模块系统也支持异步。在AMD中，你不是直接导入模块，而是定义一个模块及其依赖，然后提供一个回调函数，当所有依赖都加载完成后，这个回调函数会被调用。

AMD的API非常简洁——只需要一个函数：`define`。

```javascript // 定义一个模块 define('user', ['jQuery', 'underscore'], function($, _) { // 模块的私有实现 var _cache = {};

function _validateUserId(userId) { if (!_.isString(userId) || userId.length === 0) { throw new Error('Invalid userId'); } }

// 导出模块API return { getUserById: function(userId) { _validateUserId(userId);

if (_cache[userId]) { return $.Deferred().resolve(_cache[userId]).promise(); }

return $.ajax('/api/user/' + userId).then(function(user) { _cache[userId] = user; return user; }); },

updateUser: function(userId, data) { var us