前端模块化的演进过程

在技术日新月异的时代，像我们这些在框架和工具成熟期后进入这个行业的。对前端工程化工具生态的发展过程自然是要陌生一些。但是我认为了解一下这个过程中诞生的工具和思想，不仅会对模块化理解更深刻，可能还会带来新的启示 下面内容来源于网上。 模块化的几个代表阶段 1. 文件划分方式 最早我们会基于文件划分的方式实现模块化，也就是 Web 最原始的模块系统。具体做法是将每个功能及其相关状态数据各自单独放到不同的 JS 文件中，约定每个文件是一个独立的模块。使用某个模块将这个模块引入到页面中，一个 script 标签对应一个模块，然后直接调用模块中的成员（变量 / 函数）。 // module-a.js function foo () { console.log('moduleA#foo') } // module-b.js var data = 'something' 缺点： 模块直接在全局工作，大量模块成员污染全局作用域； 没有私有空间，所有模块内的成员都可以在模块外部被访问或者修改； 一旦模块增多，容易产生命名冲突； 无法管理模块与模块之间的依赖关系； 在维护的过程中也很难分辨每个成员所属的模块。 总之，这种原始“模块化”的实现方式完全依靠约定实现，一旦项目规模变大，这种约定就会暴露出种种问题，非常不可靠，所以我们需要尽可能解决这个过程中暴露出来的问题。 2. 命名空间方式 后来，我们约定每个模块只暴露一个全局对象，所有模块成员都挂载到这个全局对象中，通过将每个模块“包裹”为一个全局对象的形式实现，这种方式就好像是为模块内的成员添加了“命名空间”，所以我们又称之为命名空间方式。 // module-a.js window.moduleA = { method1: function () { console.log('moduleA#method1') } } // module-b.js window.moduleB = { data: 'something' method1: function () { console.log('moduleB#method1') } } 这种命名空间的方式只是解决了命名冲突的问题，但是其它问题依旧存在。 3. IIFE 使用立即执行函数表达式（IIFE，Immediately-Invoked Function Expression）为模块提供私有空间。具体做法是将每个模块成员都放在一个立即执行函数所形成的私有作用域中，对于需要暴露给外部的成员，通过挂到全局对象上的方式实现。 // module-a.js (function () { var name = 'module-a' function method1 () { console.log(name + '#method1') } window.moduleA = { method1: method1 } })() // module-b.js (function () { var name = 'module-b' function method1 () { console.log(name + '#method1') } window.moduleB = { method1: method1 } })() 这种方式带来了私有成员的概念，私有成员只能在模块成员内通过闭包的形式访问，这就解决了前面所提到的全局作用域污染和命名冲突的问题。 4.IIFE 依赖参数 在 IIFE 的基础之上，我们还可以利用 IIFE 参数作为依赖声明使用，这使得每一个模块之间的依赖关系变得更加明显。 // module-a.js ;(function ($) { // 通过参数明显表明这个模块的依赖 var name = 'module-a' function method1 () { console.log(name + '#method1') $('body').animate({ margin: '200px' }) } window.moduleA = { method1: method1 } })(jQuery) 模块化规范 以上解决了模块代码的组织问题，但模块加载的问题却被忽略了。 我们都是通过 script 标签的方式直接在页面中引入的这些模块，这意味着模块的加载并不受代码的控制，时间久了维护起来会十分麻烦。 模块化规范的出现 提到模块化规范，可能会想到 CommonJS 规范（它是 Node.js 中所遵循的模块规范）。该规范约定以同步的方式加载模块，一个文件就是一个模块，每个模块都有单独的作用域，通过 module.exports 导出成员，再通过 require 函数载入模块。 因为 Node.js 执行机制是在启动时加载模块，执行过程中只是使用模块，所以这种方式不会有问题。如果要在浏览器端使用同步的加载模式，就会引起大量的同步模式请求，导致应用运行效率低下。 所以在早期制定前端模块化标准时，并没有直接选择 CommonJS 规范，而是专门为浏览器端重新设计了一个规范，叫做 AMD （ Asynchronous Module Definition） 规范，即异步模块定义规范。（同期还推出了一个非常出名的库，叫做 Require.js，它除了实现了 AMD 模块化规范，本身也是一个非常强大的模块加载器） 在 AMD 规范中约定每个模块通过 define() 函数定义，这个函数默认可以接收两个参数，第一个参数是一个数组，用于声明此模块的依赖项；第二个参数是一个函数，参数与前面的依赖项一一对应，每一项分别对应依赖项模块的导出成员，这个函数的作用就是为当前模块提供一个私有空间。如果在当前模块中需要向外部导出成员，可以通过 return 的方式实现。 模块化的标准规范 随着技术的发展，JavaScript 的标准逐渐走向完善，可以说，如今的前端模块化已经发展得非常成熟了，而且对前端模块化规范的最佳实践方式也基本实现了统一。 在 Node.js 环境中，我们遵循 CommonJS 规范来组织模块。 在浏览器环境中，我们遵循 ES Modules 规范。 因为 CommonJS 属于内置模块系统，所以在 Node.js 环境中使用时不存在环境支持问题，只需要直接遵循标准使用 require 和 module 即可。（在最新的 Node.js 提案中表示，Node 环境也会逐渐趋向于 ES Modules 规范） 但是对于 ES Modules 规范来说，情况会相对复杂一些。我们知道 ES Modules 是 ECMAScript 2015（ES6）中才定义的模块系统，也就是说它是近几年才制定的标准，所以肯定会存在环境兼容的问题。在这个标准刚推出的时候，几乎所有主流的浏览器都不支持。但是随着 Webpack 等一系列打包工具的流行，这一规范才开始逐渐被普及。 最后 模块化可以帮助我们更好地解决复杂应用开发过程中的代码组织问题，但是随着模块化思想的引入，我们的前端应用又会产生了一些新的问题。 这些问题就由前端模块打包工具来解决，其中之一就是——Webpack（这里有打包器之间的特性对比）

本文章由javascript技术分享原创和收集