工作原理概括

基本概念

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

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

流程概括

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

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

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

流程细节

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

1. 初始化：启动构建，读取与合并配置参数，加载Plugin，实例化Complier.
2. 编译：从Entry出发，针对每个Module串行调用对应的Loader去翻译文件内容，再找到该Module依赖的Module，递归地进行编译处理。

3. 输出： 对编译后的Module组合成Chunk，把Chunk转换成文件，输出到文件系统。
   如果只执行一次构建，以上阶段将会按照顺序各执行一次。但在开启监听模式下，流程将变为如下：

   
   
   image.png
   
   

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

初始化阶段

编译阶段

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

输出阶段

在输出阶段已经得到了各个模块经过转换后的结果和其依赖关系，并且把相关模块组合在一起形成一个个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)
}