工作原理概括

基本概念

在了解webpack原理前，需要掌握以下几个核心概念，以方便后面的理解：

Entry 入口，webpack执行构建的第一步将从Entry开始，可抽象成输入
Module 模块，在webpack里一切皆模块，一个模块对应着一个文件。webpack会从配置的Entry开始递归找出所有依赖的模块。
Chunk 代码块，一个Chunk由多个模块组合而成，用于代码合并与分割。
Loader 模块转换器，用于把模块原内容按照需求转换成新内容。
Plugin 扩展插件，在webpack构建流程中特定时机会广播出对应的事件，插件可以监听这些事件的发生，在特定时机做对应的事情。

流程概括

webpack的运行流程是一个串行的过程，从启动到结束会依次执行以下流程：

初始化参数：从配置文件和Shell语句中读取与合并参数，得出最终的参数；
开始编译：用上一步得到的参数初始化Complier对象，加载所有配置的插件，执行对象的run方法开始执行编译；
确定入口：根据配置中的entry找出所有入口文件；
编译模块：从入口文件出发，调用所有配置的Loader对模块进行翻译，再找出该模块依赖的模块，再递归本步骤知道所有入口依赖的文件都经过了本步骤的处理；
完成模块编译：在经过第4步使用Loader翻译完所有模块后，得到了每个模块被翻译后的最终内容以及他们之间的依赖关系；
输出资源：根据入口和模块之间的依赖关系，组装成一个个包含多个模块的Chunk，再把每个Chunk转换成一个单独的文件加入到输出列表，这步是可以修改输出内容的最后机会；
输出完成：在确定好输出内容后，根据配置确定输出的路径和文件名，把文件内容写入到文件系统。

在以上过程中，webpack会在特定的时间点广播出特定的时间，插件在监听到感兴趣的时间后会执行特定的逻辑，并且插件可以调用Webpack提供的API改变Webpack的运行结果。

流程细节

Webpack的构建流程可以分为以下三个阶段：

初始化：启动构建，读取与合并配置参数，加载Plugin，实例化Complier.
编译：从Entry出发，针对每个Module串行调用对应的Loader去翻译文件内容，再找到该Module依赖的Module，递归地进行编译处理。
输出：对编译后的Module组合成Chunk，把Chunk转换成文件，输出到文件系统。
如果只执行一次构建，以上阶段将会按照顺序各执行一次。但在开启监听模式下，流程将变为如下：

image.png

在每个大阶段中又会发生很多时间，webpack会把这些事件广播出来供给Plugin使用，下面一一介绍

初始化阶段

事件名	解释
初始化参数	从配置文件和 Shell 语句中读取与合并参数，得出最终的参数。这个过程中还会执行配置文件中的插件实例化语句 new Plugin()。
实例化 Compiler	用上一步得到的参数初始化 Compiler 实例，Compiler 负责文件监听和启动编译。Compiler 实例中包含了完整的 Webpack 配置，全局只有一个 Compiler 实例。
加载插件	依次调用插件的 apply 方法，让插件可以监听后续的所有事件节点。同时给插件传入 compiler 实例的引用，以方便插件通过 compiler 调用 Webpack 提供的 API。
environment	开始应用 Node.js 风格的文件系统到 compiler 对象，以方便后续的文件寻找和读取。
entry-option	读取配置的 Entrys，为每个 Entry 实例化一个对应的 EntryPlugin，为后面该 Entry 的递归解析工作做准备。
after-plugins	调用完所有内置的和配置的插件的 apply 方法。
after-resolvers	根据配置初始化完 resolver，resolver 负责在文件系统中寻找指定路径的文件。

编译阶段

事件名	解释
run	启动一次新的编译
watch-run	和run类似，区别在于它是在监听模式下启动的编译，在这个事件中可以获取到是哪些文件发生了变化导致重新启动一次新的编译
compile	该事件是为了告诉插件一次新的编译将要启动，同时会给插件带上compiler对象。
compilation	当webpack以开发模式运行时，每当检测到文件变化，一次新的Compilation将被创建。一个Compilation对象包含了当前的模块资源、编译生成资源、变化的文件等。Compilation对象也提供了很多时间回调供插件做扩展。
make	一个新的Comilation创建完毕，即将从Entry开始读取文件，根据文件类型和配置的Loader对文件进行编译，编译完后再找出该文件依赖的文件，递归的编译和解析。
after-compile	一次Compilation执行完成
invalid	当遇到文件不存在、文件编译错误等异常时会触发该事件，该事件不会导致Webpack退出。

在编译阶段中，最重要的要数compilation事件了，因为在compilation阶段调用了Loader完成了每个模块的转换操作，在compilation阶段又包括很多小的事件，它们分别是：

事件名	解释
build-module	使用对应的Loader去转换一个模块
normal-module-loader	在用Loader对一个模块转换完后，使用acorn解析转换后的内容，输出对应的抽象语法树（AST），以方便Webpack后面对代码的分析
program	从配置的入口模块开始，分析其AST，当遇到require等导入其它模块语句时，便将其加入到依赖的模块列表，同时对新找出的依赖模块递归分析，最终搞清所有模块的依赖关系。
seal	所有模块及其依赖的模块都通过Loader转换完成后，根据依赖关系开始生成Chunk

输出阶段

事件名	解释
should-emit	所有需要输出的文件已经生成好，询问插件哪些文件需要输出，哪些不需要
emit	确定好要输出哪些文件，执行文件输出，可以在这里获取和修改输出内容
after-emit	文件输出完毕
done	成功完成一次玩的编译和输出流程
failed	如果在编译和输出流程中遇到异常导致webpack退出时，就会直接跳转到本步骤，插件可以在本事件中获取到具体的错误原因

在输出阶段已经得到了各个模块经过转换后的结果和其依赖关系，并且把相关模块组合在一起形成一个个Chunk。在输出阶段会根据Chunk的类型，使用对应模板生成最终要输出的文件内容。

输出文件分析

Webpack 输出的 bundle.js 是什么样子的吗？为什么原来一个个的模块文件被合并成了一个单独的文件？为什么 bundle.js 能直接运行在浏览器中？

bundle.js能直接运行在浏览器中的原因在于输出的文件中通过webpack_require函数定义了一个可以在浏览器中执行的加载函数来模拟Node.js中的require语句。

原来一个个独立的模块文件被合并到了一个单独的bundle.js的原因在于浏览器不像Node.js那样快速地去本地加载一个个模块文件，而必须通过网络请求去加载还未得到的文件。如果模块数量很多，加载时间会很长，因此把所有模块都存放到了数组中，执行一次网络加载。

如果仔细分析webpack_require函数的实现，你还会发现webpack做了缓存优化：执行加载过的模块不会再执行第二次，执行结果会缓存在内存中，当某个模块第二次被访问时会直接去内存中读取被缓存的返回值。

分割代码时的输出

例如把源码中的main.js修改为如下：

// 异步加载show.js
import('./show').then((show) => {
    // 执行show函数
    show('webpack');
})

重新构建后会输出两个文件，分别是执行入口文件bundle.js和异步加载文件0.bundle.js
其中0.bundle.js内容如下：

// 加载在本文件中包含的模块
webpackJsonp(
    // 在其它文件中存放着的模块的ID
    [0],
    // 本文件所包含的模块
    [
        // show.js所对应的模块
        (function (module, exports) {
            function show(content) {
                window.document.getElementById('app').innerText = 'Hello,' + content;
            }
            module.exports = show;
        })
    ]
);

在使用了 CommonsChunkPlugin 去提取公共代码时输出的文件和使用了异步加载时输出的文件是一样的，都会有 webpack_require.e 和 webpackJsonp。原因在于提取公共代码和异步加载本质上都是代码分割。

编写Loader

Loader就像一个翻译员，能把源文件经过转化后输出新的结果，并且一个文件还可以链式的经过多个翻译员翻译。
以处理SCSS文件为例：

SCSS源代码会先交给sass-loader把SCSS转换成CSS;
把sass-loader输出的css交给css-loader处理，找出css中依赖的资源、压缩CSS等；
把css-loader输出的css交给style-loader处理，转换成通过脚本加载的Javascript代码；

可以看出以上处理过程需要有顺序的链式执行，先sass-loader再css-loader再style-loader。

Loader的职责

由上面的例子可以看出：一个Loader的职责是单一的，只需要完成一种转换。如果一个源文件需要经历多步转换才能正常使用，就需要通过多个loader转换。在调用多个Loader去转换一个文件时，每个Loader会链式的顺序执行，第一个Loader将会拿到需处理的原内容，上一个Loader处理后的结果会传给下一个接着处理，最后的Loader将处理后的最终结果返回给Webpack.

所以，在拟开发一个Loader时，请保持其职责的单一性，你只需关心输入和输出。

Loader基础

由于Webpack是运行在Node.js之上的，一个Loader其实就是一个Node.js模块，这个模块需要导出一个函数。这个导出函数的工作就是获得处理前的原内容，对原内容执行处理后，返回处理后的内容。

一个最简单的Loader的源码如下：

module.exports = function(source) {
      // source为compiler传递给Loader的一个文件的原内容
      // 该函数需要返回处理后的内容，这里简单起见，直接把原内容返回了，相当于该Loader没有做任何转换
      return source
}

由于Loader运行在Node.js中，你可以调用任何Node.js自带的API，或者安装第三方模块进行调用：

const sass = require('node-sass')
module.exports = function(source) {
    return sass(source)
}

webpack原理