从webpack再次走进JS模块化世界

在最近阅读webpack源码和工作机制的过程中再一次认识JS模块化。
首先，为什么模块化概念对webpack如此重要？
webpack的文档给出了这样一段概念：

本质上，webpack 是一个现代 JavaScript 应用程序的静态模块打包器(module bundler)。当 webpack 处理应用程序时，它会递归地构建一个依赖关系图(dependency graph)，其中包含应用程序需要的每个模块，然后将所有这些模块打包成一个或多个 bundle

在webpack的世界里，一切皆模块

那么模块是什么？

在模块化编程中，开发者将程序分解成离散功能块(discrete chunks of functionality)，并称之为模块。每个模块具有比完整程序更小的接触面，使得校验、调试、测试轻而易举。精心编写的模块提供了可靠的抽象和封装界限，使得应用程序中每个模块都具有条理清楚的设计和明确的目的。

webapck使用loader通过 loader 可以支持各种语言和预处理器编写模块，将一切资源文件变成模块

ES2015 import 语句
CommonJS require() 语句
AMD define 和 require 语句
css/sass/less 文件中的 @import 语句。
样式(url(...))或 HTML 文件()中的图片链接(image url)

那么JS中的模块化概念是什么

其实大家是愿意把模块写在一个JS文件里面的，但是解决不了命名冲突的问题，如果写成不同的JS文件，就会难以维护，依赖模糊，请求过多...

为什么我们在JS中需要模块化

分解功能拆分代码
简化开发便于调试
解决命名空间冲突
管理依赖

Stage1： IIFE 现代模块化的基石

var myRevealingModule = (function () {
    var privateVar = "Ben Cherry",
        publicVar = "Hey there!";

    function privateFunction() {
        console.log( "Name:" + privateVar );
    }

    function publicSetName( strName ) {
        privateVar = strName;
    }

    function publicGetName() {
        privateFunction();
    }

    // Reveal public pointers to
    // private functions and properties
    return {
        setName: publicSetName,
        greeting: publicVar,
        getName: publicGetName
    };
})();

myRevealingModule.setName( "Paul Kinlan" );

这种模式在JS模块化历程中使用了很长一段时间，它利用JS中唯一的函数作用域对变量进行封装（ES2015之前）

优点

很简单，可以在任何地方实现（没有库，不需要语言支持）。
可以在单个文件中定义多个模块。

缺点

无法以编程方式导入模块（除非使用eval）。
需要手动处理依赖关系——JS中的文件经常各种依赖。
无法异步加载模块——这对浏览器可很重要。
循环依赖可能很麻烦。
静态代码分析器很难分析它。

Stage2：CommonJS和Node

CommonJS是一个旨在定义一系列规范的项目，以帮助开发服务器端JavaScript应用程序。CommonJS团队试图解决的一个领域是模块。
NodeJS遵循一部分的CommonJS规范，但是又不完全相同，在于CommonJS中使用export进行导出模块，而NodeJS使用module.export

优点

简单：开发人员可以在不查看文档的情况下掌握概念。
集成了依赖管理：模块需要其他模块并按所需顺序加载。
require 可以在任何地方调用：模块可以通过编程方式加载。
支持循环依赖。

缺点

同步API使其不适合某些用途（客户端）。
每个模块一个文件。
浏览器需要加载程序库或转换。
没有模块的构造函数（尽管Node支持这个）。
静态代码分析器很难分析。

Stage3： AMD

AMD诞生于一群对CommonJS采用的同步方式不满的开发人员。AMD和CommonJS之间的主要区别在于它支持异步模块加载。因为在浏览器的世界里，同步意味着阻塞。
AMD的核心在于通过使用JavaScript的传统闭包习惯来实现异步加载：在请求的模块加载完成时调用函数。
AMD加载程序可以在运行时获得给定项目的依赖关系图的完整画面。这对于浏览器尤为重要，因为启动时间对于良好的用户体验至关重要。
优点

异步加载（更好的启动时间）。
支持循环依赖。
兼容exports和require。
完全整合了依赖管理。
如有必要，可以将模块拆分为多个文件。
支持构造函数 这一点我还需要研究一下
插件支持（自定义加载步骤）。
缺点
语法稍微复杂一些（多一个define语法）。
除非已编译，否则需要加载程序库。
静态代码分析器很难去分析它。

Stage4： import和export 未来的新规范

import和export，静态编译器可以在编译时就构建完整的依赖树，而不需要在运行时读取依赖
关于import是同步还是异步，官网文档给了这样的答案，Support for both synchronous and asynchronous loading ，取决于引擎加载模块的方式是同步还是异步，服务器端是同步，浏览器端就是异步

优点

支持同步和异步加载。
语法简单。
支持静态分析工具。
集成在语言中（将来浏览器都支持这一边标准后，是不用像CMD和AMD那样还需要插件库去支持这一范式的）。
支持循环依赖。

缺点

暂时各大浏览器都无法原生支持。

东扯西扯

CommonJS模块：应用于服务端，同步加载，一个模块加载完了，才运行后面的代码，对服务器端来说这不是问题，因为数据储存在硬盘，基本就是读取的时间
AMD范式：异步加载模块，当加载一个模块时，不阻塞后面的代码执行，而是设置了一个回调，当模块加载完成后，回调执行业务逻辑
async和defer，都是异步加载，但是async下载完马上执行（且不保证顺序执行），defer要等到渲染后再执行（严格按照加载顺序执行）
AMD是依赖前置，先执行依赖，CMD推崇依赖就近、延迟执行
ES6和CommonJS不同点 ES6 模块与 CommonJS 模块的差异：
1. import要放在文件顶部，require不用，import是编译时的，require是运行时的（runtime），import本质上会被编译成require
2. CommonJS 模块输出的是一个值的拷贝，ES6 模块输出的是值的引用。
3. CommonJS如果输出原始类型值，如果输出后，试图去改变这个值，那么不会被改变了
4. CommonJS 模块是运行时加载，ES6 模块是编译时输出
ES6在node和浏览器中的使用
1. ES6首先被babel编译，然后如果是要跑在浏览器上，需要一些 bundler （ webpack ， browserify ）帮你处理依赖打包成能在浏览器跑的代码
2. 所以我们的项目中写了ES6的import，但是不叫做在Node中使用了ES6，而是ES6语法被babel编译了Node中使用ES6的模块
3. 浏览器中实现ES6的import 浏览器原生支持import

JavaScript Module Systems Showdown: CommonJS vs AMD vs ES2015JavaScript 模块的循环加载
模块化七日谈