Webpack加载程序顺序：什么是webpack前后加载程序，以及它们与一系列加载程序的区别

Question

我知道在最新的Webpack中，我们可以指定module.rules选项enforce: 'pre'以使某个加载程序按照docs中的指定以“ pre-loader”的身份运行。

但是我找不到关于预加载器和后加载器含义的适当解释。当然，我们当然可以从逻辑上认为“ pre”先于“ post”运行，但是我不知道确切发生了什么（为什么没有记录？）。

这也是考虑到已经有指定装载机为了看财产的方式Rule.use在该文档它说Loaders can be chained by passing multiple loaders, which will be applied from right to left (last to first configured)

所以两个相关的问题：

• chaining和pre和post之间有什么区别？
• 有没有办法在此链的顺序上有更详细的webpack日志，以了解首先运行的是什么，其次运行的是什么？

PS 1：我知道在SO上也有类似的问题，但是我发现没有一个问题链接到一份文档，该文档实际上详细解释了加载顺序

PS 2：一个简短的场景说明为什么这对我来说很重要，是我运行打字稿，tslint和babel，我想了解正确的链接过程以及各个步骤中实际发生的情况

Answer 1

为了找到答案，我a-loader.js通过h-loader.js接收内容编写了自己的加载程序，打印日志，然后返回内容。为了完整起见，每个加载程序文件都有一个正常阶段和一个投球阶段。您可以在https://webpack.js.org/api/loaders/#pitching-loader阅读有关投球装载机的信息。

a-loader.js：

module.exports = function(content) {
  console.log('Loader A, normal phase.');
  return content;
};

module.exports.pitch = function(remainingRequest, precedingRequest, data) {
  console.log('Loader A, pitching phase.');
}

除了我更改了日志语句以记录它是哪个加载器之外，所有加载器都具有相同的代码。

我的webpack-config.js看起来像这样：

  module: {
    rules: [
      {
        test: /\.js$/,
        use: [{loader: path.resolve('loaders/a-loader.js')}],
      },
      {
        test: /\.js$/,
        use: [{loader: path.resolve('loaders/b-loader.js')}]
      },
      {
        test: /\.js$/,
        use: [{loader: path.resolve('loaders/c-loader.js')}]
      },
      {
        test: /\.js$/,
        use: [{loader: path.resolve('loaders/d-loader.js')}]
      },
      {
        test: /\.js$/,
        use: [{loader: path.resolve('loaders/e-loader.js')}],
      },
      {
        test: /\.js$/,
        use: [{loader: path.resolve('loaders/f-loader.js')}]
      },
      {
        test: /\.js$/,
        use: [{loader: path.resolve('loaders/g-loader.js')}]
      },
      {
        test: /\.js$/,
        use: [{loader: path.resolve('loaders/h-loader.js')}]
      },
    ]
  }

输出：

Loader A, pitching phase.
Loader B, pitching phase.
Loader C, pitching phase.
Loader D, pitching phase.
Loader E, pitching phase.
Loader F, pitching phase.
Loader G, pitching phase.
Loader H, pitching phase.
Loader H, normal phase.
Loader G, normal phase.
Loader F, normal phase.
Loader E, normal phase.
Loader D, normal phase.
Loader C, normal phase.
Loader B, normal phase.
Loader A, normal phase.

这里并不奇怪。投球阶段首先运行，然后正常阶段运行。正如您所指出的，正常相位加载器从右到左应用。h在正常阶段中是第一个，因为它在阵列（链）中最右边。我有一个有用的方法来记住投球顺序。想想正常的相序，想象一个投影在正常顺序之上的镜像。镜像是投球顺序。

接下来，我将其调整webpack.config.js为以下内容：

Loader A, pitching phase.
Loader B, pitching phase.
Loader C, pitching phase.
Loader D, pitching phase.
Loader E, pitching phase.
Loader F, pitching phase.
Loader G, pitching phase.
Loader H, pitching phase.
Loader H, normal phase.
Loader G, normal phase.
Loader F, normal phase.
Loader E, normal phase.
Loader D, normal phase.
Loader C, normal phase.
Loader B, normal phase.
Loader A, normal phase.

输出：

Loader D, pitching phase.
Loader F, pitching phase.
Loader B, pitching phase.
Loader C, pitching phase.
Loader E, pitching phase.
Loader G, pitching phase.
Loader A, pitching phase.
Loader H, pitching phase.
Loader H, normal phase.
Loader A, normal phase.
Loader G, normal phase.
Loader E, normal phase.
Loader C, normal phase.
Loader B, normal phase.
Loader F, normal phase.
Loader D, normal phase.

暂时忽略俯仰阶段，因为记住它们只是正常阶段的镜像。考虑enforce: pre并post喜欢分组。“前”是第一组，然后是未标记的“正常”组，最后是“后”组。在正常阶段，第一个加载器是h因为它在“pre”组中并且在数组中最右边。接下来是a因为它是“pre”组中唯一的另一个。接下来是“取消组合” g，e，c，b从右到左。最后，“post”组f和d，按从右到左的顺序运行。

我不知道为什么在 webpack 站点上没有更好地记录这一点。