前端模块化简单梳理
本篇简介
关于前端模块化的一些知识，如CMD/AMD/Webpack等，之前都进行过专门学习，但经验尚欠，无法从上层理解模块化处于前端工程的哪一层，所以此篇文章暂且抛开之前所学内容，不做细化研究，先单独对模块化大致脉络进行梳理，等待后续工程化、设计模式等学习完成后再进行整体的梳理。
整体脉络图
1. 无模块化时期
Web初期并没有模块化的工具，且前端在当时相对轻量，甚至后端通过模板就能完全胜任全栈工程师的角色，所以当时并没有前端工程的概念，也就没有模块化。为了组织代码，采用的是不同功能代码通过文件区分：
<!-- 不同功能代码通过文件区分，导入模板，但作用域并没分离 -->
<script src="layer.js"></script>
<script src="init.js"></script>
<script src="login.js"></script>
2. 【幼年期】语法层面模块化
由于无模块化会导致全局变量污染问题，不利于团队开发，因此 IIFE 自然成了语法层面模块化的唯一选择；其原理是函数作用域内变量若存在外部引用，则函数产生引用时的执行环境不会销毁，也就是此时函数作用域一直生效，且由于外部无法访问函数内部作用域，因此就形成了即封闭又长效的“模块”。IIFE只是将匿名函数立即执行，是对上述原理的一种语法简化，用它实现模块化的方式是返回一个暴露 api 的对象（模块）：
// IIFE
var moduleA = (() => {
var count = 0;
return {
printCount: function() {
console.log(count); // 对函数作用域中的count进行引用
},
increase: function() {
count++;
}
};
})();
// 调用模块
moduleA.printCount(); // 0
moduleA.increase();
moduleA.printCount(); // 1
面试题1：有额外依赖时，如何优化 IIFE？
由于 IIFE 原理是借助函数作用域，所以额外依赖可以通过参数传入函数中供模块使用：
// IIFE
var moduleA = ((dependB, dependC) => {
var count = dependB.count || dependC.count || 0; // 使用依赖
return {
printCount: function() {
console.log(count); // 对函数作用域中的count进行引用
},
increase: function() {
count++;
}
};
})(moduleB, moduleC);
面试题2：了解 jQuery早期依赖处理及模块化加载方案吗？
使用了揭示模式（Revealing）写法，原理仍然是 IIFE 传参，匿名函数暴露 api 对象，api 写法是指针形式：
const moduleA = ((dep1, dep2) => {
var count = dep1.count || dep2.count || 0;
var getCount = function() {
return count;
};
return {
getCount, // 揭示模式写法，用指针代替具体函数
};
})(moduleB, moduleC);
3. 【成熟期】CommonJS 的出现
Node 作为服务端语言出现后，自然少不了模块化的需求，因此出现了 CommonJS。其特性如下：
- require 引入依赖模块
- module、exports 对象暴露 api
模块组织方式如下：
/* NodeJS模块，基于CommonJS规范 */
// 引入依赖
const dep1 = require('./dep1.js');
// coding
let count = de1.count || 0; // 使用模块
const getCount = () => count;
// 暴露api
exports.getCount = getCount;
// 也可以直接重写module.exports
module.exports = {
getCount,
}
优缺点如下：
- 优点：从框架层面首次实现了真正意义的模块化
- 缺点：为服务端设计，所以起初并未考虑异步依赖问题
面试题：上述CommonJS模块实际执行过程是？
由于对异步依赖支持不足，所以不难想到早期原理是 IIFE 的语法糖：
(function(thisValue, exports, require, module) {
const dep1 = require('./dep1.js');
// ...
}).call(thisValue, exports, require, module);
4. AMD规范
CommonJS 解决了模块化的问题，但又有了如何处理异步依赖的新问题，而 AMD规范应运而生。原理是 “异步加载后，执行回调函数”，经典框架是 require.js。示例如下：
/**
* @function define函数能够定义模块，require函数加载模块
* @params 模块名，依赖列表，模块工厂函数
*/
// 定义模块
define(id, [...dependList], factory);
// 引入模块
require([...moduleList], callback); // 加载模块，完成后执行callback
demo如下：
// 定义moduleA模块
define('moduleA', ['dep1', 'dep2'], (dep1, dep2) => {
let count = dep1.count || dep2.count || 0;
const getCount = () => count;
return {
getCount,
};
});
// 引入并使用模块
require(['moduleA'], moduleA => {
moduleA.getCount(); // 0
});
面试题1：若希望AMD兼容之前CommonJS代码，怎么办？
AMD引入依赖的方式除了传入列表，还给工厂函数提供了 require方法，能够兼容CommonJS的写法：
define('moduleA', [], require => {
let dep1 = require('./dep1.js');
let dep2 = require('./dep2.js');
let count = dep1.count || dep2.count || 0;
const getCount = () => count;
return {
getCount,
};
});
面试题2：AMD使用 revealing 写法？
除了返回对象，也可以使用工厂函数的 export 对象挂载指针，虽然是一种设计模式，但其实写法没太大区别：
define('moduleA', [], (require, exports, module) => {
let dep1 = require('./dep1.js');
let dep2 = require('./dep2.js');
let count = dep1.count || dep2.count || 0;
const getCount = () => count;
exports.getCount = getCount; // 直接挂载export对象
});
AMD的优缺点：
- 优点：可在浏览器中加载模块，且支持异步、并行得加载多个模块
- 缺点：无法按需加载
还有一种能够兼容 AMD 和 CommonJS 的规范叫 UMD，原理就是在工厂函数外包裹一层兼容函数，通过不同传参实现兼容，在这里不过多展开。
5. CMD规范
由于AMD无法按需加载，国内团队做了CMD规范进行优化，主流框架是 seaJS，示例如下：
/**
* @function 省去依赖列表参数，依赖动态引入，与AMD区分是能按需加载
*/
define('moduleA', (require, exports, module) => {
let $ = require('jquery');
//...jquery相关逻辑
let dep1 = require('./dep1');
// ...dep1相关逻辑
});
优缺点：
- 优点：在打包时能够实现按需加载，且依赖就近，方便维护
- 缺点：按需加载会使打包过程变慢，且按需加载逻辑放入每个模块，模块体积反而会增大
面试题：AMD & CMD 的区别？
CMD能够按需加载
6. 【新时代】ES模块化
从 ES6 开始，实现了JS模块化的标准语法，且能实现上述旧工具的所有功能，并得到了良好支持。示例如下：
// 引入依赖
import dep1 from './dep1'
let count = 0;
function getCount() {
return count;
}
// 导出接口
export default {
getCount,
}
浏览器中引入模块的方法是 type=module 的script标签：
<script type="module" src="./moduleA.js"></script>
新版 Node中直接使用 ES6语法引入即可：
// 模块文件一般用 mjs 后缀
import moduleA from './moduleA.mjs'
// 使用模块
moduleA.getCount();
面试题：ES6 如何实现动态加载模块？
Webpack 支持使用 CMD写法或 import('./moduleA')，不过 ES11 已原生支持该特性：
// 原理就是包一层promise，等模块加载完就引入
import('./moduleA').then(dynamicModule => {
dynamicModule.getCount();
});
ES6模块化的优缺点：
- 优点：通过统一且标准的方式实现了模块化
- 缺点：若不使用Webpack 等工程化工具，其本质仍然是运行时依赖分析
7. 【完备方法】工程化
为了解决 ES6 是运行时依赖分析的痛点，使用工程化构建工具，使依赖能够在代码构建阶段就完成。典型工具有 grunt、gulp、webpack，大致原理如下：
<script>
// 构建工具的占位符
// require.config(__FRAME_CONFIG__);
</script>
<script>
import A from './modA'
define('B', () => {
let c = require('C');
// 业务逻辑
});
</script>
编译时会扫描依赖关系并生成map：
{
a: [],
b: ['c'],
}
然后会根据依赖关系替换占位符：
<script>
require.config({
a: [],
b: ['c'],
})
</script>
接着会根据模块化工具的配置处理依赖并生成符合兼容要求的代码：
// 同步方案，加载进C
define('b', ['c'], () => {
// ...
})
完成。
这种方案的优点：
- 构建时分析依赖
- 方便拓展，比如同时使用3种不同的模块化方案
总结
大概梳理一下模块化的脉络，有助于理解现在为何Webpack、Vite 等工具流行的原因，因为能解决足够多的问题，将多规范进行统一并且可以拓展。若想研究具体的规范使用，可以参考对应热门框架的实现，每一个都可以讲很多东西，在这里不过多阐述。
