首先掌实，模塊系統(tǒng)主要解決模塊的定義蓖议，依賴和導(dǎo)出，先看看已經(jīng)存在的模塊系統(tǒng)琼掠。
1：<script>標(biāo)簽
<script src="module1.js"></script>
<script src="module2.js"></script>
<script src="libraryA.js"></script>
<script src="module3.js"></script>
這是最原始的 JavaScript 文件加載方式，如果把每一個(gè)文件看做是一個(gè)模塊停撞，那么他們的接口通常是暴露在全局作用域下眉枕，也就是定義在 window
對(duì)象中，不同模塊的接口調(diào)用都是一個(gè)作用域中怜森，一些復(fù)雜的框架速挑，會(huì)使用命名空間的概念來(lái)組織這些模塊的接口，典型的例子如 YUI 庫(kù)副硅。
這種原始的加載方式暴露了一些顯而易見(jiàn)的弊端：
- 全局作用域下容易造成變量沖突+
- 文件只能按照 <script> 的書(shū)寫順序進(jìn)行加載
- 開(kāi)發(fā)人員必須主觀解決模塊和代碼庫(kù)的依賴關(guān)系
- 在大型項(xiàng)目中各種資源難以管理姥宝，長(zhǎng)期積累的問(wèn)題導(dǎo)致代碼庫(kù)混亂不堪
2：CommonJS
服務(wù)器端的 Node.js 遵循 CommonJS規(guī)范，該規(guī)范的核心思想是允許模塊通過(guò) require方法來(lái)同步加載所要依賴的其他模塊恐疲，然后通過(guò) exports或 module.exports來(lái)導(dǎo)出需要暴露的接口腊满。
require("module");
require("../file.js");
exports.doStuff = function() {};
module.exports = someValue;
優(yōu)點(diǎn)：
- 服務(wù)器端模塊便于重用
- NPM 中已經(jīng)有將近20萬(wàn)個(gè)可以使用模塊包
- 簡(jiǎn)單并容易使用
缺點(diǎn)：
- 同步的模塊加載方式不適合在瀏覽器環(huán)境中套么，同步意味著阻塞加載，瀏覽器資源是異步加載的
- 不能非阻塞的并行加載多個(gè)模塊
實(shí)現(xiàn)：
- 服務(wù)器端的 Node.js
- Browserify碳蛋，瀏覽器端的 CommonJS 實(shí)現(xiàn)胚泌，可以使用 NPM 的模塊，但是編譯打包后的文件體積可能很大
- modules-webmake肃弟，類似Browserify玷室，還不如 Browserify 靈活
- wreq，Browserify 的前身
3：AMD
Asynchronous Module Definition 規(guī)范其實(shí)只有一個(gè)主要口 define(id?, dependencies?, factory)笤受，它要在聲明模塊的時(shí)候指定所有的依賴 dependencies穷缤，并且還要當(dāng)做形參傳到 factory中，對(duì)于依賴的模塊提前執(zhí)行箩兽，依賴前置津肛。
define("module", ["dep1", "dep2"], function(d1, d2) {
return someExportedValue;
});
require(["module", "../file"], function(module, file) { /* ... */ });
優(yōu)點(diǎn)：
- 適合在瀏覽器環(huán)境中異步加載模塊
- 可以并行加載多個(gè)模塊
缺點(diǎn)：
- 提高了開(kāi)發(fā)成本，代碼的閱讀和書(shū)寫比較困難汗贫，模塊定義方式的語(yǔ)義不順暢
- 不符合通用的模塊化思維方式身坐，是一種妥協(xié)的實(shí)現(xiàn)
實(shí)現(xiàn)：
4：CMD
Common Module Definition 規(guī)范和 AMD 很相似，盡量保持簡(jiǎn)單落包，并與 CommonJS 和 Node.js 的 Modules 規(guī)范保持了很大的兼容性掀亥。
define(function(require, exports, module) {
var $ = require('jquery');
var Spinning = require('./spinning');
exports.doSomething = ...
module.exports = ...
})
優(yōu)點(diǎn)：
- 依賴就近，延遲執(zhí)行
- 可以很容易在 Node.js 中運(yùn)行
缺點(diǎn)：
- 依賴 SPM 打包妥色，模塊的加載邏輯偏重
實(shí)現(xiàn)：
5：UMD
Universal Module Definition 規(guī)范類似于兼容 CommonJS 和 AMD 的語(yǔ)法糖，是模塊定義的跨平臺(tái)解決方案遏片。
6：ES6 模塊
EcmaScript6 標(biāo)準(zhǔn)增加了 JavaScript 語(yǔ)言層面的模塊體系定義嘹害。ES6 模塊的設(shè)計(jì)思想，是盡量的靜態(tài)化吮便，使得編譯時(shí)就能確定模塊的依賴關(guān)系笔呀，以及輸入和輸出的變量。CommonJS 和 AMD 模塊髓需，都只能在運(yùn)行時(shí)確定這些東西许师。
優(yōu)點(diǎn)：
- 容易進(jìn)行靜態(tài)分析
- 面向未來(lái)的 EcmaScript 標(biāo)準(zhǔn)
缺點(diǎn)：
- 原生瀏覽器端還沒(méi)有實(shí)現(xiàn)該標(biāo)準(zhǔn)
- 全新的命令字，新版的 Node.js才支持
實(shí)現(xiàn)：
7：前端模塊加載
前端模塊要在客戶端中執(zhí)行僚匆，所以他們需要增量加載到瀏覽器中微渠。
模塊的加載和傳輸，我們首先能想到兩種極端的方式咧擂，一種是每個(gè)模塊文件都單獨(dú)請(qǐng)求逞盆，另一種是把所有模塊打包成一個(gè)文件然后只請(qǐng)求一次。顯而易見(jiàn)松申，每個(gè)模塊都發(fā)起單獨(dú)的請(qǐng)求造成了請(qǐng)求次數(shù)過(guò)多云芦，導(dǎo)致應(yīng)用啟動(dòng)速度慢俯逾；一次請(qǐng)求加載所有模塊導(dǎo)致流量浪費(fèi)、初始化過(guò)程慢舅逸。這兩種方式都不是好的解決方案桌肴，它們過(guò)于簡(jiǎn)單粗暴。
分塊傳輸琉历，按需進(jìn)行懶加載坠七，在實(shí)際用到某些模塊的時(shí)候再增量更新，才是較為合理的模塊加載方案善已。
要實(shí)現(xiàn)模塊的按需加載灼捂，就需要一個(gè)對(duì)整個(gè)代碼庫(kù)中的模塊進(jìn)行靜態(tài)分析、編譯打包的過(guò)程换团。
8：所有資源都是模塊
在上面的分析過(guò)程中悉稠，我們提到的模塊僅僅是指JavaScript模塊文件。然而艘包，在前端開(kāi)發(fā)過(guò)程中還涉及到樣式的猛、圖片、字體想虎、HTML 模板等等眾多的資源卦尊。這些資源還會(huì)以各種方言的形式存在，比如 coffeescript舌厨、 less岂却、 sass、眾多的模板庫(kù)裙椭、多語(yǔ)言系統(tǒng)（i18n）等等躏哩。
如果他們都可以視作模塊，并且都可以通過(guò)require的方式來(lái)加載揉燃，將帶來(lái)優(yōu)雅的開(kāi)發(fā)體驗(yàn)扫尺，比如：
require("./style.css");
require("./style.less");
require("./template.jade");
require("./image.png");
那么如何做到讓 require 能加載各種資源呢？
9：靜態(tài)分析
在編譯的時(shí)候炊汤，要對(duì)整個(gè)代碼進(jìn)行靜態(tài)分析正驻，分析出各個(gè)模塊的類型和它們依賴關(guān)系，然后將不同類型的模塊提交給適配的加載器來(lái)處理抢腐。比如一個(gè)用 LESS 寫的樣式模塊姑曙，可以先用 LESS 加載器將它轉(zhuǎn)成一個(gè)CSS 模塊，在通過(guò) CSS 模塊把他插入到頁(yè)面的 <style> 標(biāo)簽中執(zhí)行迈倍。Webpack 就是在這樣的需求中應(yīng)運(yùn)而生渣磷。
同時(shí)，為了能利用已經(jīng)存在的各種框架授瘦、庫(kù)和已經(jīng)寫好的文件醋界，我們還需要一個(gè)模塊加載的兼容策略竟宋，來(lái)避免重寫所有的模塊。
