webpack 模块化机制

为什么需要模块化？

随着网站内容越来越复杂，浏览器和用户的交互越来越细腻，网站再也不是简单的内容呈现，更像是一个复杂的客户端软件，其中html/css/js代码越来越多，逻辑越来越复杂，越来越不便于管理，为了解决这个问题，才出现了模块化的概念，也就是说模块化更多的是工程方面的产出，为了应对更复杂的网站开发。

梳理下网站的发展过程，大家也就知道为什么模块化是必然出现的了：
✦ 早期一个html文件，通过style引入内联css，通过script引入内联js。
✦ 晚一点一个html，通过link引入外部css，通过script引入外部js。
✦ 再复杂一点，多个html，各自引入自己的css和js。
✦ 再复杂一点，多个html中有复用的css和js，怎么办呢？拆分文件呗，将css和js拆分成小文件，然后通过link和script分别引入或者手动合并之后引入。
✦ 再复杂一点，有很多js/css的小文件，手动解决会有缺陷或者容易出错，怎么办呢？引入自动化工具呗，自动合并，压缩等。
✦ 再复杂一点，想要按需合并js/css小文件，开发模式自动监听改动，甚至可以将图片等其他静态资源当做模块。
✦ 再复杂一点，…

到现在为止，都有哪些优秀的模块化方案呢？

非模块

通过多个script标签引入多个js文件，也即通过文件的方式来管理模块。

这种原始的方案有很多显而易见的弊端：
✦ 污染全局作用域，多人协作简直是灾难。
✦ 手动维护script标签的顺序，多页应用更惨。
✦ 大型项目资源难以管理，容易留下隐患。

CommonJs，同步require

该方案的核心思想就是允许模块通过require方案同步加载依赖的其他模块，通过exports或module.exports来暴露出需要的接口。

require(“../moduleA.js”);

exports.doStuff = function() {
console.log(‘hello world’);
};
这种原始的方案的优点：
✦ 复用性强。
✦ 有不少可以拿来即用的模块，生态不错。
✦ 实现简单，使用简单。

这种原始的方案的弊端：
✦ 同步加载不适合浏览器，浏览器的请求都是异步加载。
✦ 不能并行加载多个模块。

AMD，异步require

该方案只有一个主要接口define(id?, dependencies?, factory)，他要在声明模块的时候指定所有的依赖dependencies，并传入到factory中，对于依赖的模块异步加载并执行。

// 定义
define(“mymodule”, [“dep1”, “dep2”], function(d1, d2) {
});

// 加载
require([“module”, “../file”], function(module, file) {
});
这种原始的方案的优点：
✦ 异步加载适合浏览器。
✦ 可并行加载多个模块。

这种原始的方案的弊端：
✦ 模块定义方式不优雅，不符合标准模块化

ES6模块

该方案最大的特点就是静态化，静态化的优势在于可以在编译的时候确定模块的依赖关系以及输入输出的变量。上面提到的CommonJs和AMD都只能在运行时确定这些东西。

import “jquery”;
export function doStuff() {}
这种原始的方案的优点：
✦ 可静态分析，提前编译。
✦ 面向未来的标准。

这种原始的方案的弊端：
✦ 浏览器原生兼容性差，所以一般都编译成ES5。
✦ 目前可以拿来即用的模块少，生态差。

webpack模块化机制

webpack并不强制你使用某种模块化方案，而是通过兼容所有模块化方案让你无痛接入项目，当然这也是webpack牛逼的地方。
有了webpack，你可以随意选择你喜欢的模块化方案，至于怎么处理模块之间的依赖关系及如何按需打包，放轻松，webpack会帮你处理好的。

webpack的模块化有什么特点？

✦ 可以兼容多模块风格，无痛迁移老项目。
✦ 一切皆模块，js/css/图片/字体都是模块。
✦ 静态解析，按需打包，动态加载。

require(“./style.css”);
require(“./style.less”);
require(“./template.jade”);
require(“./image.png”);
本来，模块化方案仅仅是针对JS。但实际项目中，我们希望coffeescript也能被当做模块，进一步，css/less/sass是不是也可以被当做模块，再进一步，html/image/template是不是也可以被当做模块。
想到这些就觉得脑洞大开，不可思议！但是webpack居然做到了！webpack提供的loaders可以对文件做预处理，从而实现了一切皆模块。

那么，webpack到底对模块代码做了什么？

非模块化代码

一行alert(‘hello world’);代码，经过webpack打包后，会生成如下50行代码；

/**/ (function(modules) { // webpackBootstrap
/**/ // The module cache
/**/ var installedModules = {};

/**/ // The require function
/**/ function webpack_require(moduleId) {

/**/ // Check if module is in cache
/**/ if(installedModules[moduleId])
/**/ return installedModules[moduleId].exports;

/**/ // Create a new module (and put it into the cache)
/**/ var module = installedModules[moduleId] = {
/**/ exports: {},
/**/ id: moduleId,
/**/ loaded: false
/**/ };

/**/ // Execute the module function
/**/ modules[moduleId].call(module.exports, module, module.exports, webpack_require);

/**/ // Flag the module as loaded
/**/ module.loaded = true;

/**/ // Return the exports of the module
/**/ return module.exports;
/**/ }

/**/ // expose the modules object (webpack_modules)
/**/ webpack_require.m = modules;

/**/ // expose the module cache
/**/ webpack_require.c = installedModules;

/**/ // webpack_public_path
/**/ webpack_require.p = “”;

/**/ // Load entry module and return exports
/**/ return webpack_require(0);
/**/ })
/**************************************************************/
/**/ ([
/* 0 */
/*/ function(module, exports) {

alert('hello world');

/*/ }
/**/ ]);
上面编译出来的代码主要包含两个部分：Runtime，模块。上半部分就是Runtime，作用是保证模块顺序加载和运行。下半部分是我们的JS代码，包裹了一个函数，也就是模块。
运行的时候模块是作为Runtime的参数被传进去的。

(function(modules) {
// Runtime
})([
// 模块数组
])
那么，非模块化代码被编译后会有什么缺陷呢？
✦ 模块不再暴露在全局作用域，模块的全局变量也不再是全局变量。
✦ 模块被引入的时候只是执行代码而无法将模块赋值。因为非模块化规范的代码没有通过AMD的return或者CommonJs的exports导出模块本身。

AMD模块

AMD的代码

define([], function() {
alert(‘hello world!’);
});
经过webpack打包，会生成如下核心代码：

function(module, exports, webpack_require) {
var WEBPACK_AMD_DEFINE_ARRAY, // AMD依赖列表
WEBPACK_AMD_DEFINE_RESULT; // AMD factory函数的返回值，即模块内容

__WEBPACK_AMD_DEFINE_ARRAY__ = [];// 执行factory函数，获取返回值作为模块内容// 函数体使用.apply调用，函数体中this为exports// 形参则分别对应依赖列表中的各个依赖模块__WEBPACK_AMD_DEFINE_RESULT__ = function() {    alert('hello world!');}.apply(exports, __WEBPACK_AMD_DEFINE_ARRAY__);// 如果模块内容不为空，则通过module.exports返回// 如果为空，则不处理，在Runtime中声明为{}if (__WEBPACK_AMD_DEFINE_RESULT__ !== undefined) {    module.exports = __WEBPACK_AMD_DEFINE_RESULT__;}

}
CommonJs

CommonJs的代码

var me = {
sayHello:function(){
alert(‘hello world!’);
}
};
module.exports = me;
经过webpack打包，会生成如下核心代码：

function(module, exports) {
var me = {
sayHello: function() {
alert(‘hello world!’);
}
};

module.exports = me;

}
模块化是拆分，那传输怎么办？

博文开头提到，模块化是工程化的需求，是为了更好的管理代码，最后上线的代码并不应该是这样的，假设我们用两个极端的方式去加载代码：
✦ N个模块N个请求。
✦ 所有模块打包成一个文件，一个请求。
显然，这两种都不是最优方案，第一种请求数量过多，第二种请求文件过大。

理论上，最优方案是：按需打包，即将该页面需要的所有模块打包成一个文件，保证请求最少，且请求的代码都是需要的。

在webpack之前的构建工具里，都实现不了这个“最优方案”，因为它们不知道模块之前的依赖关系，自然就不能按需打包了。
而webpack出现之后，它的代码分片功能让webpack拥有了按需打包的特性，从而鹤立鸡群。当然，webpack还有很多其他优秀的特性。

作者：齐修_qixiuss
链接：http://www.jianshu.com/p/ee88e9849a1b
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。