Webpack加载器订购:webpack前后加载器是什么以及它们与加载器链的区别

时间:2018-01-19 10:38:18

标签: webpack webpack-2

我在最新的Webpack中得到了这个,我们可以指定module.rules选项enforce: 'pre'来使某个加载器作为"预加载器"运行。如the docs中所述。

但我无法找到预加载器和后加载器意味着什么的正确解释。当然,我们可以逻辑地认为" pre"在" post"之前运行但我没有得到确切发生的事情(为什么没有记录?)。

这也在考虑已经有一种方法来指定加载器顺序,查看the docsRule.use的{​​{1}}属性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:关于为什么这对我来说很重要的一个简短场景是我运行typescript,tslint和babel,我想了解正确的链接过程以及各个步骤中实际发生的事情

1 个答案:

答案 0 :(得分:6)

要找到答案,我编写了自己的装载器a-loader.jsh-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调整为以下内容:

  module: {
    rules: [
      {
        test: /\.js$/,
        use: [{loader: path.resolve('loaders/a-loader.js')}],
        enforce: "pre"
      },
      {
        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')}],
        enforce: "post"
      },
      {
        test: /\.js$/,
        use: [{loader: path.resolve('loaders/e-loader.js')}],
      },
      {
        test: /\.js$/,
        use: [{loader: path.resolve('loaders/f-loader.js')}],
        enforce: "post"
      },
      {
        test: /\.js$/,
        use: [{loader: path.resolve('loaders/g-loader.js')}]
      },
      {
        test: /\.js$/,
        use: [{loader: path.resolve('loaders/h-loader.js')}],
        enforce: "pre"
      },
    ]
  }

输出:

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: prepost视为分组。 “ pre”组是第一个组,未标记的是前组,最后是“ post”组。在正常阶段,第一个加载器为h,因为它位于“ pre”组中,并且在阵列中最右边。下一个是a,因为它是“上一个”组中的唯一另一个。接下来是从右到左的“未分组的” gecb。最后,“发布”组fd以从右到左的顺序运行。

我不知道为什么在Webpack网站上没有对此进行更好的记录。