如何正确配置Webpack 5打包引入其他模块的Web Worker脚本

核心错误是你为.worker.js后缀文件单独配置了type: "asset/resource"规则。
Webpack 5 原生Web Worker能力会自动识别new Worker(new URL(..., import.meta.url))语法，将匹配到的Worker文件作为独立JS入口，自动完成依赖解析、代码转译、合并打包全流程。你手动配置的asset/resource规则会强制Webpack将匹配到的文件作为普通静态资源处理，直接复制文件到输出目录，完全跳过JS模块构建环节，所以文件内的import语句不会被解析，引入的第三方依赖、本地模块也不会被打包进最终产物。
这也解释了为什么Worker脚本没有import语句时可以正常运行：纯原生JS代码即使被直接复制也能在浏览器执行，一旦涉及模块导入就必须经过构建流程处理。

1. 删除错误的静态资源规则 #

移除webpack配置中专门针对.worker.js的asset/resource规则，不要手动干预Worker文件的默认处理逻辑，避免打断Webpack原生的Worker构建流程。

2. 调整babel-loader匹配范围 #

将.worker.js从babel-loader的排除列表中移除，让Worker文件和普通业务JS文件一样走babel转译流程，修改后的babel规则配置如下：

{
  test: /\.js$/,
  exclude: /(node_modules)/, // 移除原有对.worker.js的排除配置
  use: {
    loader: "babel-loader", // 复用现有babel.config.js的转译规则
  },
}

3. 配置Worker文件输出路径 #

如果需要将Worker文件统一输出到js/workers子目录，不要使用asset模块的generator配置，而是通过Webpack内置的output.workerChunkFilename配置项实现，配置示例如下：

module.exports = {
  entry: {...},
  output: {
    // 保留原有output配置，比如path、publicPath、filename等
    workerChunkFilename: 'js/workers/[hash].js', // 单独指定Worker产物的存储路径和命名规则
  },
  module: {
    rules: [
      // 放入调整后的babel-loader规则，其余业务loader规则保持不变
    ]
  }
}

4. 主线程调用代码无需额外修改 #

你原有主线程的Worker调用逻辑可以正常运行，不需要做特殊调整，示例代码如下：

const worker = new Worker(
  new URL("../workers/listOperation.worker.js", import.meta.url),
  {
    type: "module",
  },
);
worker.postMessage({ list: hugeList, params: reqData });
worker.onerror = err => console.error(err);
worker.onmessage = e => {
  const { list } = e.data;
  // 处理响应返回的list数据
  worker.terminate();
};
return worker;

• 不需要额外引入worker-loader，Webpack 5 原生Web Worker支持已经覆盖对应能力，混用第三方loader反而会导致构建异常。
• 不要将Worker文件放在public这类直接复制的静态资源目录下，否则会跳过Webpack构建流程，同样会出现依赖未打包的问题。

重新执行构建后，Worker文件内引入的lodash方法、本地常量等依赖都会被完整打包转译，产物中不会残留未处理的import/require语句，可以直接在浏览器中正常运行。

内容的提问来源于stack exchange，提问作者Debajit Majumder