Loader的执行顺序与链式调用

Loader的执行顺序

Webpack中的Loader执行顺序遵循从右到左、从下到上的原则。这个顺序看起来可能有些反直觉，但实际上与函数组合的概念一致。当多个Loader应用于同一个资源时，它们会形成一个处理管道，每个Loader的输出会成为下一个Loader的输入。

module.exports = {
  module: {
    rules: [
      {
        test: /\.scss$/,
        use: [
          'style-loader',  // 第三个执行
          'css-loader',   // 第二个执行
          'sass-loader'   // 第一个执行
        ]
      }
    ]
  }
};

在这个SCSS处理示例中，执行顺序实际上是：

1. sass-loader将SCSS编译为CSS
2. css-loader解析CSS中的@import和url()
3. style-loader将CSS注入到DOM中

链式调用的本质

Loader的链式调用实际上是函数组合的体现。Webpack内部会将Loader数组转换为一个函数调用链，每个Loader都是一个转换函数，接收前一个Loader的输出作为输入。这种设计模式类似于Unix管道或函数式编程中的compose操作。

// 伪代码表示Loader链的执行过程
const output = styleLoader(cssLoader(sassLoader(input)));

执行顺序的例外情况

虽然大多数情况下Loader从右向左执行，但有两种特殊情况会改变这个顺序：

1. pitch阶段：Loader可以通过pitch方法实现从左向右的执行
2. enforce属性：可以强制改变Loader的执行顺序

module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        use: [
          { loader: 'babel-loader', enforce: 'pre' },  // 最先执行
          { loader: 'eslint-loader', enforce: 'post' } // 最后执行
        ]
      }
    ]
  }
};

pitch阶段的执行机制

每个Loader实际上由两部分组成：常规Loader和pitch方法。pitch阶段的执行顺序与常规阶段完全相反，是从左到右的。

// Loader的pitch方法示例
module.exports = function(content) {
  // 常规Loader逻辑
  return transformedContent;
};

module.exports.pitch = function(remainingRequest, precedingRequest, data) {
  // pitch阶段逻辑
  // 可以提前返回结果来跳过后续Loader
};

完整的执行流程如下：

1. 从左到右执行所有Loader的pitch方法
2. 从右到左执行所有Loader的常规方法

enforce属性的优先级

enforce属性可以强制改变Loader的执行顺序，它有四个可能的值：

• pre：在所有普通Loader之前执行
• post：在所有普通Loader之后执行
• normal：普通Loader（默认）
• inline：行内Loader（通过import语句指定）

执行优先级顺序为：pre > normal > inline > post

module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        enforce: 'pre',
        use: ['eslint-loader']
      },
      {
        test: /\.js$/,
        use: ['babel-loader']
      },
      {
        test: /\.js$/,
        enforce: 'post',
        use: ['cleanup-loader']
      }
    ]
  }
};

行内Loader的特殊处理

行内Loader通过资源路径中的!分隔符指定，它们的执行顺序有些特殊：

import Styles from 'style-loader!css-loader!sass-loader!./styles.scss';

行内Loader的执行顺序是从左到右，与配置中的Loader相反。它们会在normal Loader之后、post Loader之前执行。

实际应用中的常见模式

理解Loader执行顺序后，可以构建更高效的构建流程。例如，处理TypeScript时：

module.exports = {
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        use: [
          {
            loader: 'babel-loader',
            options: {
              presets: ['@babel/preset-env', '@babel/preset-react']
            }
          },
          {
            loader: 'ts-loader',
            options: {
              transpileOnly: true
            }
          }
        ]
      }
    ]
  }
};

这个配置先使用ts-loader将TypeScript转换为JavaScript，然后通过babel-loader进行进一步转换和polyfill处理。

Loader的数据传递机制

Loader之间可以通过loaderContext.data共享数据，这在复杂转换流程中非常有用：

// loader1.js
module.exports = function(source) {
  this.data.value = 'shared data';
  return source;
};

// loader2.js
module.exports = function(source) {
  const sharedValue = this.data.value; // 获取loader1设置的值
  return source + '\n// ' + sharedValue;
};

性能优化考虑

Loader的执行顺序直接影响构建性能。一些优化建议：

1. 尽量减少Loader数量
2. 将耗时的Loader放在处理链的后面
3. 使用enforce: 'pre'处理不需要转换的Loader
4. 利用cache-loader缓存中间结果

module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        use: [
          'cache-loader',
          'babel-loader'
        ]
      }
    ]
  }
};

调试Loader执行顺序

可以通过自定义Loader来调试执行顺序：

// debug-loader.js
module.exports = function(source) {
  console.log(`[Loader Debug] ${this.loaderIndex}: ${this.loaders[this.loaderIndex].path}`);
  return source;
};

// webpack.config.js
module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        use: [
          'debug-loader',
          'babel-loader',
          'debug-loader'
        ]
      }
    ]
  }
};