从前端模块化的概念来理解Webpack

为什么需要模块化？

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

>在ES6之前，前端模块的实现本质都是利用JS神器：闭包。 闭包使得函数在调用时可以访问该函数定义时的词法作用域，通过作用域查找所有声明的标识符（变量），达到不暴露私有作用域。

基础模块

    function myModule() {
        var _something = 'xxoo'
        var _another = [1,2,3];
        function dosomething() {
            console.log(_something);
        }
        function doAnother() {
            console.log(_another.join('!'));
        }
        return {
            dosomething: dosomething,
            doAnother: doAnother
        }
    }

    var foo = myModule();
    foo.dosomething(); //xxoo
    foo.doAnother(); //1!2!3

解析：
myModule()只是一个函数，通过调用它来创建一个模块实例，不执行的话，内部作用域和闭包都无法创建，其次返回一个对象字面量，返回的对象中含有对内部函数的引用而不是内部数据变量的引用（函数的嵌套才能形成闭包），

从模块中返回一个实际的对象并不是必须的，也可以直接返回一个内部函数，类似jQuery，jQeury和$标识符就是jQuery模块的公共API，但它们本身都是函数（由于函数也是对象，所以也可以拥有属性）。

模块模式需要具备两个必要条件

• 必须有外部的封闭函数，该函数至少被调用一次（每次调用都会创建一个新的模块实例）。

• 封闭函数必须至少返回一个内部函数，这样内部函数才能在私有作用域中形成闭包，并且可以访问或者修改私有的状态。

现代的模块机制

大多数模块依赖加载器本质上都是将这种模块定义封装进一个友好的API。比如requiresjs，以下代码是简单的实现。

    var MyModules = (function Manager () {
        var modules = {};
        function define(name, deps, impl) {
            for(var i=0; i<deps.length; i++) {
                //依赖变量赋值，找到相应的模块方法
                deps[i] = modules[deps[i]];
            }
            modules[name] = impl.apply(impl, deps);//传入依赖的模块名作为参数，以便该模块调用
        }
        function get(name) {
            return modules[name];
        }
        return {
            define: define,
            get: get,
        }
    })();

这段代码的核心是modules[name] = impl.apply(impl, deps)。为了模块的定义引入了包装函数（可以传入任何依赖），并且将返回值，也就是模块的API，存储在一个根据名字来管理的模块列表中。

下面展示了如何使用它来定义模块：

    MyModules.define('bar', [], function() {
        function hello(who) {
            return 'i am ' + who;
        }
        return {hello: hello};
    });

    MyModules.define('foo', ['bar'], function(bar) {
        function awesome() {
            console.log(bar.hello('kenny').toUpperCase());
        }
        return {
            awesome: awesome
        }
    })

    var bar = MyModules.get('bar');
    var foo = MyModules.get('foo');

    console.log(bar.hello('kenny')); // i am kenny

    console.log(foo.awesome('kenny'));// I AM KENNY

解读：
MyModules是一个立即执行函数（单例模式），返回对象字面量（含有对内部函数define和get的引用，形成闭包），所以当执行define的时候，define方法可以查找MyModules的词法作用域，其次deps[i]=modules[depsi]，也形成闭包，当有依赖时，impl通过查找该参数（dep[i]）来获取API，从而其他方法可以找到该依赖的方法。在私有对象modules里， get方法共享MyModules的词法作用域，从而可以获取define时的模块方法。

可以研究示例代码深入理解下闭包的作用，最重要的是要理解模块管理器没有任何特殊的“魔力”，它们符合前面列出的模块模式的两个特点：　调用了包装函数定义的包装函数，　并且将返回值作为该模块的ＡＰＩ。

换句话说，模块就是模块，即使在它们外层加上一个友好的包装工具也不会发生任何变化。

现代的模块机制

ES6为模块增加了一级语法支持。在通过模块系统加载时，ES6会将文件当作独立的模块来处理，每个模块可以导入其他模块或特定的API成员，同样也可以导出自己的API成员。

该方案最大的特点就是静态化（API不会在运行时被改变），静态化的优势在于可以在编译的时候确定模块的依赖关系以及输入输出的变量。如果PAI引用不存在，编译器会在编译时就抛出‘早期’错误，而不会等到运行时期再动态解析。

ES6的模块必须被定义在独立的文件中（一个文件一个模块）。

import "jquery";
export function doStuff() {}

webpack的模块有什么特点

• 1：可以兼容多模块风格，无痛迁移老项目。

• 2：一切皆模块，js/css/图片/字体都是模块。

• 3：静态解析，按需打包，动态加载。

webpack并不强制你使用某种模块化方案，而是通过兼容所有模块化方案让你无痛接入项目，当然这也是webpack牛逼的地方。

有了webpack，你可以随意选择你喜欢的模块化方案，至于怎么处理模块之间的依赖关系及如何按需打包，webpack会帮你处理好的。

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/this导出模块本身。

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

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还有很多其他优秀的特性。

wepback按需打包及拆分可以参考这篇文章

参考：

• 书籍《你不知道的javascript上卷》

• webpack模块化机制