webpack的loader机制
loader本质上就是导出函数的JavaScript模块。导出的函数,可以用来实现内容的转换。
/*
* @param{string|Buffer} content 源文件的内容
* @param{object} [map] SourceMap数据
* @param{any} [meta] meta数据,可以是任何数据
* */
function webpackloader(context, map, meta) {
}
module.exports = webpackloader()
Normal Loader
Normal Loader: 按照正常的顺序去执行的loader
use参数,表示匹配到test中匹配对应的文件应该使用那个loader的队则去处理,use可以为一个字符串也可以为一个数组,use为一个数组的时候,表示有多个loader一次处理匹配的资源,按照从右到左,从下到上执行
如果要改变执行顺序的话,需要使用enforce参数来改变loader的执行顺序,pre前置,post后置,normal普通和inline行内
Pitching Loader
在webpack的loader中配置pitch属性,支持三个参数
/*
* @remainingReqquest 剩余请求
* @precedingRequest 前置请求
* @data 数据对象
* */
function webpackloader(remainingRequest, precedingRequest, data) {
// some code
}
data用于数据参数,在pitch函数中往data对象上添加数据,之后在normal函数中通过this.data的方法读取已经添加的数据。
remainingRequest 表示在当前 loader 处理完毕后,还需要被后续 loader 处理的请求字符串。这个字符串由剩余的 loader 路径以 ! 分隔符组成,从右到左排列。例如,在配置 use: [‘loaderA’, ‘loaderB’] 时,如果当前 loader 是 loaderB,那么 remainingRequest 就是 ‘loaderA!’(如果还有其他 loader,则继续以 ! 分隔)。
precedingRequest 表示在 pitch 阶段已经迭代过的 loader 路径字符串,同样以 ! 分隔符组成。这个字符串表示在当前 loader 的 pitch 方法被调用之前,已经有哪些 loader 的 pitch 方法被调用过
关于loader的执行阶段分为两个阶段
- 在处理资源文件之前,会经历pitch阶段
- pitch结束之后,读取资源文件内容
- 经过pitch处理后,读取到了资源文件,此时才会将读取到的资源文件内容交给正常的loader进行处理
module.exports = {
module: {
rules: [
{
test: /\.js$/,
use: ['normal1-loader', 'normal2-loader']
},
{
test: /\.js$/,
use: ['pre1-loader', 'pre2-loader'],
enforce: 'pre'
},
{
test: /\.js$/,
use: ['post1-loader', 'post2-loader'],
enforce: 'post',
}
]
}
}
故loader的执行顺序就是pitching阶段,调用loader.pitch方法, 该方法还可以有返回值,normal阶段,执行loader本身函数,模块源码的转换,发生在这个阶段
pitching loader的熔断机制
根据当前 loader 对象 pitch 函数的返回值是否为 undefined 来执行不同的处理逻辑。如果 pitch 函数返回了非 undefined 的值,则会出现熔断。即跳过后续的执行流程,开始执行上一个 loader 对象上的 normal loader 函数。