上一篇我们经历了一次头脑爆炸，一口气看完了从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/_babel-loader@8.0.4@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生成一个函数。
具体的源码解析，我们以后慢慢补充。
