6 JS的模块化 ES6模块化及webpack打包 ES6详解八：模块（Module）

转自：https://blog.csdn.net/u014168594/article/details/77198729

js的模块化进程

现在前端技术日新月异，对于同一个问题痛点，各个时段有各自的解决方案，这就带来了很大差异。今天我就打算梳理js模块化的历史进程，讲一讲这些方案要做什么，怎么做。

js模块化进程的起因

现今的很多网页其实可以看做是功能丰富的应用，它们拥有着复杂的JavaScript代码和一大堆依赖包。当一个项目开发的越来越复杂的时候，你会遇到一些问题：命名冲突（变量和函数命名可能相同），文件依赖（引入外部的文件数目、顺序问题）等。

JavaScript发展的越来越快，超过了它产生时候的自我定位。这时候js模块化就出现了。

什么是模块化

模块化开发是一种管理方式，是一种生产方式，一种解决问题的方案。他按照功能将一个软件切分成许多部分单独开发,然后再组装起来,每一个部分即为模块。当使用模块化开发的时候可以避免刚刚的问题，并且让开发的效率变高，以及方便后期的维护。

js模块化进程

一、早期：script标签

这是最原始的 JavaScript 文件加载方式，如果把每一个文件看做是一个模块，那么他们的接口通常是暴露在全局作用域下，也就是定义在 window 对象中。

缺点： 
1.污染全局作用域 
2.只能按script标签书写顺序加载 
3.文件依赖关系靠开发者主观解决

二、发展一：CommonJS规范

允许模块通过require方法来同步加载（同步意味阻塞）所要依赖的其他模块，然后通过module.exports来导出需要暴露的接口。

// module add.js
module.exports = function add (a, b) { return a + b; }

// main.js
var {add} = require('./math');
console.log('1 + 2 = ' + add(1,2);

• 1
• 2
• 3
• 4
• 5
• 6
• 7

CommonJS 是以在浏览器环境之外构建JavaScript 生态系统为目标而产生的项目，比如在服务器和桌面环境中。

三、发展二：AMD/CMD

（1）AMD

AMD 是 RequireJS 在推广过程中对模块定义的规范化产出（异步模块定义）。

AMD标准中定义了以下两个API：

1. require([module], callback);
2. define(id, [depends], callback);

require接口用来加载一系列模块，define接口用来定义并暴露一个模块。

扫描二维码关注公众号，回复： 1290833 查看本文章

    define(['./a', './b'], function(a, b) {  
        // 依赖必须一开始就写好   
        a.add1()    
        ...  
        b.add2()    
        ...
    }) 

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

优点： 
1、适合在浏览器环境中异步加载模块 2、可以并行加载多个模块

（2）CMD

CMD 是 SeaJS 在推广过程中对模块定义的规范化产出。(在CommomJS和AMD基础上提出)

define(function (requie, exports, module) { 
    //依赖可以就近书写 
    var a = require('./a'); 
    a.add1(); 
    ... 
    if (status) { 
        var b = requie('./b'); 
        b.add2(); 
    } 
}); 

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11

优点： 
1、依赖就近，延迟执行 2、可以很容易在服务器中运行

（3）AMD 和 CMD 的区别

AMD和CMD起来很相似，但是还是有一些细微的差别：

1、对于依赖的模块，AMD是提前执行，CMD是延迟执行。

2、AMD推崇依赖前置；CMD推崇依赖就近，只有在用到某个模块的时候再去require。

3、AMD 的 API 默认是一个当多个用，CMD 的 API 严格区分，推崇职责单一

四、发展三：ES6模块化

EcmaScript6 标准增加了JavaScript语言层面的模块体系定义。

在 ES6 中，我们使用export关键字来导出模块，使用import关键字引用模块。

// module math.jsx
export default class Math extends React.Component{}

// main.js
import Math from "./Math";

• 1
• 2
• 3
• 4
• 5
• 6

目前很少JS引擎能直接支持 ES6 标准，因此 Babel 的做法实际上是将不被支持的import翻译成目前已被支持的require。

ES6详解八：模块（Module）

基本用法

命名导出(named exports)

可以直接在任何变量或者函数前面加上一个 export 关键字，就可以将它导出。 
这种写法非常简洁，和平时几乎没有区别，唯一的区别就是在需要导出的地方加上一个 export 关键字。 
比如：

export const sqrt = Math.sqrt;
export function square(x) {
    return x * x;
}
export function diag(x, y) {
    return sqrt(square(x) + square(y));
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

然后在另一个文件中这样引用：

import { square, diag } from 'lib';
console.log(square(11)); // 121
console.log(diag(4, 3));

• 1
• 2
• 3
• 4

你可能会注意到这个奇怪的语法 { square, diag } 不就是前面讲过的 destructing吗。所以你会以为还可以这样写：

 import lib from 'lib';
 square = lib.square;

• 1
• 2
• 3

但是其实这样是错的，因为 import { square, diag } from 'lib’; 是import的特有语法，并不是 destructing 语法，所以其实import的时候并不是直接把整个模块以对象的形式引入的。

如果你希望能通过 lib.square 的形式来写，你应该这样导入：

 import * as lib from 'lib';
 square = lib.square;

• 1
• 2
• 3

不过值得注意的一点是，如果你直接用babel编译，执行是会报错的。因为 babel 并不会完全编译 modules，他只是把 ES6 的modules语法编译成了 CMD 的语法，所以还需要用 browserify 之类的工具再次编译一遍。 
如果你发现 browserify 找不到 lib，可以改成 from ‘./lib’ 试试。

默认导出

大家会发现上面的写法比较麻烦，因为必须要指定一个名字。其实很多时候一个模块只导出了一个变量，根本没必要指定一个名字。 
还有一种用法叫默认导出，就是指定一个变量作为默认值导出：

 //------ myFunc.js ------
export default function () { ... };

//------ main1.js ------
import myFunc from 'myFunc';
myFunc();

• 1
• 2
• 3
• 4
• 5
• 6
• 7

默认导出的时候不需要指定一个变量名，它默认就是文件名。 
这里的区别不仅仅是不用写名字，而是 导出的默认值就是模块本身，而不是模块下面的一个属性，即是 import myFunc from 'myFunc’; 而不是 import {myFunc} from 'myFunc’;

命名导出结合默认导出

默认导出同样可以结合命名导出来使用：

export default function (obj) {
    ...
};
export function each(obj, iterator, context) {
    ...
}
export { each as forEach };

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

上面的代码导出了一个默认的函数，然后由导出了两个命名函数，我们可以这样导入：

 import _, { each } from 'underscore';

• 1
• 2

注意这个逗号语法，分割了默认导出和命名导出

其实这个默认导出只是一个特殊的名字叫 default，你也可以就直接用他的名字，把它当做命名导出来用，下面两种写法是等价的：

import { default as foo } from 'lib';
import foo from 'lib';

• 1
• 2
• 3

同样的，你也可以通过显示指定 default 名字来做默认导出, 下面两种写法是一样的：

 //------ module1.js ------
export default 123;

//------ module2.js ------
const D = 123;
export { D as default };

• 1
• 2
• 3
• 4
• 5
• 6
• 7

仅支持静态导入导出

ES6规范只支持静态的导入和导出，也就是必须要在编译时就能确定，在运行时才能确定的是不行的，比如下面的代码就是不对的：

//动态导入
var mylib;
if (Math.random()) {
    mylib = require('foo');
} else {
    mylib = require('bar');
}
//动态导出
if (Math.random()) {
    exports.baz = ...;
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12

为什么要这么做，主要是两点：

1. 性能，在编译阶段即完成所有模块导入，如果在运行时进行会降低速度
2. 更好的检查错误，比如对变量类型进行检查

各种导入和导出方式总结

总结一下，ES6提供了如下几种导入方式：

// Default exports and named exports
import theDefault, { named1, named2 } from 'src/mylib';
import theDefault from 'src/mylib';
import { named1, named2 } from 'src/mylib';

// Renaming: import named1 as myNamed1
import { named1 as myNamed1, named2 } from 'src/mylib';

// Importing the module as an object
// (with one property per named export)
import * as mylib from 'src/mylib';

// Only load the module, don’t import anything
import 'src/mylib';

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15

如下几种导出方式：

 //命名导出
export var myVar1 = ...;
export let myVar2 = ...;
export const MY_CONST = ...;

export function myFunc() {
    ...
}
export function* myGeneratorFunc() {
    ...
}
export class MyClass {
    ...
}
// default 导出
export default 123;
export default function (x) {
    return x
};
export default x => x;
export default class {
    constructor(x, y) {
        this.x = x;
        this.y = y;
    }
};
//也可以自己列出所有导出内容
const MY_CONST = ...;
function myFunc() {
    ...
}

export { MY_CONST, myFunc };
//或者在导出的时候给他们改个名字
export { MY_CONST as THE_CONST, myFunc as theFunc };

//还可以导出从其他地方导入的模块
export * from 'src/other_module';
export { foo, bar } from 'src/other_module';
export { foo as myFoo, bar } from 'src/other_module';

浅谈webpack打包原理

模块化机制

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

关于模块化的一些内容，可以看看我之前的文章：js的模块化进程

核心思想：

1. 一切皆模块： 
   正如js文件可以是一个“模块（module）”一样，其他的（如css、image或html）文件也可视作模 块。因此，你可以require(‘myJSfile.js’)亦可以require(‘myCSSfile.css’)。这意味着我们可以将事物（业务）分割成更小的易于管理的片段，从而达到重复利用等的目的。
2. 按需加载： 
   传统的模块打包工具（module bundlers）最终将所有的模块编译生成一个庞大的bundle.js文件。但是在真实的app里边，“bundle.js”文件可能有10M到15M之大可能会导致应用一直处于加载中状态。因此Webpack使用许多特性来分割代码然后生成多个“bundle”文件，而且异步加载部分代码以实现按需加载。

文件管理

• 每个文件都是一个资源，可以用require/import导入js
• 每个入口文件会把自己所依赖(即require)的资源全部打包在一起，一个资源多次引用的话，只会打包一份
• 对于多个入口的情况，其实就是分别独立的执行单个入口情况，每个入口文件不相干(可用CommonsChunkPlugin优化)

打包原理

把所有依赖打包成一个bundle.js文件，通过代码分割成单元片段并按需加载。

如图，entry.js是入口文件，调用了util1.js和util2.js，而util1.js又调用了util2.js。

打包后的bundle.js例子

/******/ ([
/* 0 */     //模块id
/***/ function(module, exports, __webpack_require__) {

    __webpack_require__(1);     //require资源文件id
    __webpack_require__(2);

/***/ },
/* 1 */
/***/ function(module, exports, __webpack_require__) {
    //util1.js文件
    __webpack_require__(2);
    var util1=1;
    exports.util1=util1;

/***/ },
/* 2 */
/***/ function(module, exports) {
    //util2.js文件
    var util2=1;
    exports.util2=util2;

/***/ }
...
...
/******/ ]);

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27

1. bundle.js是以模块 id 为记号，通过函数把各个文件依赖封装达到分割效果，如上代码 id 为 0 表示 entry 模块需要的依赖， 1 表示 util1模块需要的依赖
2. require资源文件 id 表示该文件需要加载的各个模块，如上代码_webpack_require__(1) 表示 util1.js 模块，__webpack_require__(2) 表示 util2.js 模块
3. exports.util1=util1 模块化的体现，输出该模块