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 函数。