webpack - style-loader的pitch方法如何引入css-loader处理结果？

Question

style-loader的pitch方法是先于css-loader执行的，这时候css loader处理的内容还没有生成，那么style-loader是如何引入css-loader处理的结果的？

查阅资料，说的是会通过引用requestpath:

const requestPath = loaderUtils.stringifyRequest(this, '!!' + remainingRequest);

// requestPath为:
// '!!../node_modules/css-loader/index.js!../node_modules/less-loader/dist/cjs.js!src/styles/index.less'

return `

const content = require(${requestPath})
const style = document.createElement('style');
style.innerHTML = content;
document.head.appendChild(style);

`;
};

这个path会中断loader的执行，并且执行css-loader。那么requestpath是如何被webapck处理的呢？把本次loader会执行require(${requestPath})吗？

以下是声明的loader配置

module.exports = {
  entry: "./src/main.js",//入口文件
  output: {//出口文件
    path: path.resolve(__dirname, "build"),
    filename:"bundle.js"
  },
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          'style-loader',
          'css-loader'
        ]
      },
      {
       test: /\.less$/,
         use: [
          'style-loader',
          'css-loader',
          'less-loader'
         ]
      }
   ]  
 }
}

Answer 1

Webpack 如何处理loader中新依赖
当 style-loader 生成新依赖时，Webpack 会通过以下步骤将其添加到依赖图中：

步骤 1：Loader 返回新依赖
style-loader 的 pitch 函数返回了一段 JavaScript 代码，其中包含 require 语句。Webpack 会为这些代码构建moduel，并解析这些 require 语句，提取出新的依赖路径，形成新的dependency实例。

步骤 2：调用 addDependency
Webpack 在解析模块时，会调用 addDependency 方法，将新依赖添加到当前模块的依赖列表中。例如：

javascript
复制
this.addDependency(remainingRequest); // 添加 CSS 文件依赖
this.addDependency(runtimePath); // 添加运行时代码依赖
步骤 3：递归处理依赖
Webpack 会递归处理这些新依赖，对每个依赖重复模块加载、Loader 处理、依赖解析等步骤，直到所有依赖都被处理完毕。

步骤 4：更新依赖图
Webpack 会将这些依赖关系更新到依赖图（ModuleGraph）中，确保模块之间的依赖关系正确。

也就是说，style-loader执行完pitch方法后，会就结束了本次loader链的执行。webpack接收到它返回的内容，构建module，并解析内容中的依赖，形成对应的dependency实例，然后又收集dependency的loaders，构建新的loader链处理dependency。

Answer 2

答案：

style-loader 的 pitch 方法通过 Webpack 的内联 require 机制和 !! 前缀规则，强制中断后续 loader 执行流程，直接获取 css-loader 处理后的结果。以下是关键实现原理：

1. pitch 方法特性：

   • loader 的执行分为 pitch阶段（从左到右）和 normal阶段（从右到左）
   • 如果 pitch 方法返回非 undefined 值，会跳过后续 loader 的执行流程

2. requestPath 的作用：

   const requestPath = '!!css-loader!less-loader!./src/styles.less'

   • !! 前缀表示禁用所有配置中的 loader，只使用内联指定的 loader
   • 这避免了 loader 循环调用问题（否则会再次进入 style-loader）

3. Webpack 处理流程：

   1. 当 pitch 方法返回的代码包含 require(${requestPath}) 时
   2. Webpack 会将其识别为特殊的内联请求

   3. 重新创建一个新的模块处理链：

      Entry -> less-loader -> css-loader

   4. css-loader 会将 CSS 转换为 JS 模块（包含字符串化的 CSS 内容）

4. 代码生成示例：
   生成的最终代码类似：

   const content = __webpack_require__("!!css-loader!less-loader!./src/styles.less");
   const style = document.createElement('style');
   style.innerHTML = content.toString(); // 获取 css-loader 处理后的结果
   document.head.appendChild(style);

验证配置的示例：
对于你的 less 规则配置：

use: ['style-loader', 'css-loader', 'less-loader']

实际执行顺序为：

1. pitch 阶段：style-loader(pitch) -> css-loader(pitch) -> less-loader(pitch)
2. 当 style-loader 的 pitch 方法返回代码时，会跳过后续 pitch 阶段
3. 直接通过内联 require 调用 !!css-loader!less-loader!xxx.less 获取处理结果

关键点总结：

• !! 前缀创建了一个新的独立 loader 处理链
• 内联 require 会触发新的编译过程（绕过当前 loader 配置）
• style-loader 最终插入的是经过完整处理的 CSS 字符串