[FE] webpack群侠传（五）：hooks原理

上一篇我们经历了一次头脑爆炸，一口气看完了从webpack-cli到babel-loader的全流程。
这一篇可以放松一下了，
来看看hooks中到底包含了什么秘密。

1. hooks回顾

我们知道在webpack Compiler.js中第536行，
this.compile中调用了hooks.make，

compile(callback) {
    const params = this.newCompilationParams();
    this.hooks.beforeCompile.callAsync(params, err => {
        if (err) return callback(err);

        this.hooks.compile.call(params);

        const compilation = this.newCompilation(params);

        this.hooks.make.callAsync(compilation, err => {
            if (err) return callback(err);

            compilation.finish();

            compilation.seal(err => {
                if (err) return callback(err);

                this.hooks.afterCompile.callAsync(compilation, err => {
                    if (err) return callback(err);

                    return callback(null, compilation);
                });
            });
        });
    });
}

结果 this.hooks.make.callAsync(compilation, err => {
居然会跳转到，SingleEntryPlugin.js 文件中。

compiler.hooks.make.tapAsync(
    "SingleEntryPlugin",
    (compilation, callback) => {
        const { entry, name, context } = this;

        const dep = SingleEntryPlugin.createDependency(entry, name);
        compilation.addEntry(context, dep, name, callback);
    }
);

这其中发生了什么？
为了理解这一点，我们还得从webpack plugin说起。

2. webpack插件的编写方式

我认为从用例中学习代码库，会把事情变简单，
因为代码的设计目的，就是为它的使用场景服务的。

所以，一开始我们不宜直接研究hooks是如何实现的，
而是看看hooks的设计者们，期望它被如何使用。

hooks最常见的使用场景，就是当我们在给webpack编写插件的时候，
插件中会实现compiler和compilation对象的多个hooks，
下面我们来创建一个webpack 插件。

2.1 test-plugin.js

在我们的debug-webpack工程中，我们在根目录中新建一个test-plugin.js文件。

module.exports = class Plugin {
    apply(compiler) {
        compiler.hooks.make.tapAsync('TestPlugin', (compilation, callback) => {
            compilation.hooks.buildModule.tap('TestPlugin', module => {
                console.log('module.resource', module.resource);
                console.log('module.loaders', module.loaders);
                console.time('TestPlugin');
            });

            compilation.hooks.succeedModule.tap('TestPlugin', module => {
                console.timeEnd('TestPlugin');
            });

            callback();
        });
    }
};

它导出了一个类，这个类必须实现apply方法。

其中，apply方法的形参是compiler，
就是webpack-cli中调用的compiler.run的那个compiler。
至于更细节的问题，我们以后可以再慢慢看。

（1）compiler.hooks.make.tapAsync
compiler.hooks.make.tapAsync实现了compiler.hooks.make，
如果我们增加了这个实现，
webpack Compiler.js 第536行 build 调用 this.hooks.make.callAsync(compilation, err => {
会额外触发我们这里的实现。

因为它是异步的，所以我们最后要调用 callback 来完成调用。

compiler.hooks.make.tapAsync('TestPlugin', (compilation, callback) => {
    ...
    
    callback();
});

（2）compilation.hooks.buildModule.tap
compilation.hooks.buildModule.tap 实现了compilation.hooks.buildModule，
它会在webpack Compilation.js 第617行，buildModule中，
执行this.hooks.buildModule.call(module); 时被调用。

buildModule(module, optional, origin, dependencies, thisCallback) {
    ...

    this.hooks.buildModule.call(module);
    module.build(
    ...
}

因此，通过将compiler.hooks和compilation.hooks的调用和实现分离，
相当于在webpack执行过程中，添加了多个切面（面向切面编程AOP）。
在这些切面中，webpack插件可以做自己想做的任何事情。

以上test-plugin.js插件，我们只是统计了一下，
从compilation.buildModule到compilation.succeedModule 所经历的时间。

注：compilation.hooks.succeedModule在Compilation.js 第652行调用。

this.hooks.succeedModule.call(module);

2.2 在webpack.config.js中使用插件

const path = require('path');
const TestPlugin = require('./test-plugin');

module.exports = {
    entry: {
        index: path.resolve(__dirname, 'src/index.js'),
    },
    output: {
        path: path.resolve(__dirname, 'dist/'),
    },
    module: {
        rules: [
            { test: /\.js$/, use: { loader: 'babel-loader', query: { presets: ['@babel/preset-env'] } } },
        ]
    },
    plugins:[
        new TestPlugin(),
    ],
};

我们在webpack.config.js中引入了test-plugin.js，
然后在导出对象中增加了plugins属性。

这样我们的webpack插件就编写完了。

2.3 查看插件的调用效果

直接调用npm run build，

$ npm run build
module.resource ~/Test/debug-webpack/src/index.js
module.loaders [ { options: { presets: [Array] },
    ident: 'ref--4',
    loader: '~/Test/debug-webpack/node_modules/[email protected]@babel-loader/lib/index.js' } ]
TestPlugin: 213.301ms

我们统计出来，build ./src/index.js 源文件，
从compilation.hooks.buildModule到compilation.hooks.succeedModule，
总共花费了 213.301ms。

3. Tapable

上文中我们通过hooks的用例，了解了它的使用方式，
它为Compiler和Compilation两个类实现了多个切面，
下面我们来看一下原理。

我们打开Compiler类的源码，位于Compiler.js 第40行，
它是Tapable的子类，它是从tapable模块中导出的，
tapable是一个独立的代码库（v1.1.0）。

直接阅读tapable源码会发现非常难懂，
HookCodeFactory.js 中使用了大量的元编程手段new Function。

fn = new Function(
    this.args(),
    '"use strict";\n' +
    this.header() +
    this.content({
        onError: err => `throw ${err};\n`,
        onResult: result => `return ${result};\n`,
        onDone: () => "",
        rethrowIfPossible: true
    })
);

我认为在这种情况下，要想更好的理解它，最好的办法是从动机入手，
在tapable仓库README.md中，
我们看到，tapable实现了interception（拦截器）。

const { SyncHook } = require('tapable');

const hook = new SyncHook(['x', 'y']);

hook.intercept({
    register(...args) {
        console.log('2. in: register', args);
    },
    call(...args) {
        console.log('4. in: call', args);
    },
});

console.log('1. start: register');
hook.tap('some-message', (...args) => {
    console.log('5. in: tap', args);
});

console.log('3. start: call');
hook.call(1, 2, 3);

日志信息如下，

1. start: register
2. in: register [ { type: 'sync', fn: [Function], name: 'some-message' } ]
3. start: call
4. in: call [ 1, 2 ]
5. in: tap [ 1, 2 ]

注：
hooks在构造时设置了两个参数（x和y），
但是在调用时用了三个参数（1，2和3），结果第三个参数丢失了。

我们看到，每一个hooks在被调用的时候它都可以拦截到，被添加新的实现时也是如此。
我们知道ES6 proxy也可以用来实现拦截功能，
但是IE却一直是不支持的。

因此，tapable中采用了兼容性的做法，对实现hooks的代码进行了动态修改，
在其前后增加了拦截器，最后再通过new Function生成一个函数。

具体的源码解析，我们以后慢慢补充。

---

参考

webpack: plugins
Aspect-oriented programming
tapable v1.1.0