Webpack 5.109.1 修复代码生成与 ESM 重导出顺序问题

Webpack 5.109.1 是一次补丁版本更新，重点不在新增打包能力，而在修正几个容易被边缘语法、模块处理顺序和懒编译清理流程触发的问题。对于维护大型前端工程、Node.js Bundle 或自定义开发服务器的团队，这类修复的价值在于减少“源码合法，但生成结果异常”以及“换个入口顺序，输出就不同”的不确定性。

多余分号不只是格式问题

本次更新修复了一个代码生成问题：导入调用之后，如果紧跟带括号的序列元素，Webpack 可能插入多余分号。

这类问题看起来很像压缩结果不够漂亮，但它实际涉及 JavaScript 语法结构。打包器需要把动态导入、逗号表达式、括号和运行时代码拼接成合法程序；一个位置错误的分号可能改变表达式边界，严重时会造成语法错误或执行顺序变化。

项目中可能出现类似下面的结构：

const jobs = [
  import("./feature.js"),
  (console.log("feature requested"), Promise.resolve("ready")),
];

Promise.all(jobs).then(([feature, status]) => {
  console.log(feature.default(), status);
});

这里第二个数组元素使用了带括号的逗号表达式。它不是推荐到处使用的写法，但代码生成器、转译器和部分框架插件确实可能产生这种结构。Webpack 的职责是保持其语义，而不是因为插入分隔符改变程序。

可以建立一个最小回归项目，检查 5.109.1 生成的 Bundle 是否至少通过语法检查：

mkdir webpack-51091-check
cd webpack-51091-check
npm init -y
npm install --save-dev webpack@5.109.1 webpack-cli
mkdir src

cat > src/feature.js <<'EOF'
export default function feature() {
  return "feature loaded";
}
EOF

cat > src/index.js <<'EOF'
const jobs = [
  import("./feature.js"),
  (console.log("feature requested"), Promise.resolve("ready")),
];

Promise.all(jobs).then(([feature, status]) => {
  console.log(feature.default(), status);
});
EOF

cat > webpack.config.js <<'EOF'
const path = require("node:path");

module.exports = {
  mode: "production",
  entry: "./src/index.js",
  output: {
    path: path.resolve(__dirname, "dist"),
    filename: "main.js",
    clean: true,
  },
};
EOF

npx webpack
node --check dist/main.js

这段脚本是一个可自行扩展的回归用例，并不等同于补丁对应问题的完整复现。实际项目应把曾经失败的源码、Loader 产物或插件生成代码加入测试夹具。

require(esm) 分析不再依赖模块处理顺序

另一个修复涉及 require(esm) 与 module.exports 重导出分析。Webpack 5.109.1 让这项分析独立于模块处理顺序。

模块处理顺序不应该成为构建语义的一部分。入口排列、缓存命中情况、并行构建或依赖图的细微变化，都可能影响内部遍历顺序。如果分析结果依赖“哪个模块先被处理”，同一份源码就可能出现以下症状：

• 调整入口数组后，导出结果发生变化；
• 冷构建失败，热构建或二次构建成功；
• 开启缓存后才暴露问题；
• CommonJS 与 ESM 互操作结果在不同环境中不一致。

尤其是在逐步从 CommonJS 迁移到 ESM 的代码库中，经常能看到聚合导出层：

// src/bridge.js
module.exports = require("./esm-entry.mjs");

// src/esm-entry.mjs
export const version = "1.0.0";
export default function run() {
  return "ok";
}

补丁的关键意义是让相关重导出判断由模块关系决定，而不是由处理时机决定。升级后仍应针对自己的运行目标测试互操作行为，因为 Node.js 版本、Webpack 的 target、输出格式以及依赖包的 exports 配置都会影响最终结果。

一个实用的验证方式是分别执行干净构建和连续构建，并比较产物哈希：

rm -rf dist node_modules/.cache
npx webpack --mode production
find dist -type f -print0 | sort -z | xargs -0 sha256sum > /tmp/build-clean.sha256

npx webpack --mode production
find dist -type f -print0 | sort -z | xargs -0 sha256sum > /tmp/build-warm.sha256

diff -u /tmp/build-clean.sha256 /tmp/build-warm.sha256

如果 Bundle 包含构建时间、随机 ID 或其他非确定性插件输出，哈希自然可能不同。此时应改为执行导出断言，而不是只比较文件字节。

懒编译后端清理更加稳健

更新摘要还提到 lazy-compilation 后端清理过程中的异常忽略处理。由于可用摘要中的具体错误名称并不完整，不宜进一步推断它针对哪个运行时错误；可以确定的是，这项修改位于懒编译后端的清理路径，而不是正常模块编译主流程。

清理阶段常发生在开发服务器关闭、监听器撤销、客户端断开或编译器释放资源时。这里的错误如果没有正确区分，容易造成两种相反后果：

• 可安全忽略的关闭竞态导致进程以错误状态退出；
• 真正需要调查的资源泄漏被过度吞掉。

使用 experiments.lazyCompilation 的项目可以这样配置一个验证环境：

// webpack.config.js
const path = require("node:path");

module.exports = {
  mode: "development",
  entry: "./src/index.js",
  output: {
    path: path.resolve(__dirname, "dist"),
    filename: "main.js",
    clean: true,
  },
  experiments: {
    lazyCompilation: {
      entries: false,
      imports: true,
    },
  },
};

更新后重点观察启动、触发动态导入、停止开发进程这一整条生命周期，而不只是确认首次编译成功。自定义 lazy-compilation backend 的团队还应检查关闭钩子、Socket 清理和未处理 Promise 拒绝日志。

如何安全升级

Webpack 5.109.1 属于补丁版本，通常适合优先进入持续集成，但仍不建议跳过产物和运行时验证。可以按下面的顺序执行：

npm install --save-dev webpack@5.109.1
npm ls webpack
rm -rf node_modules/.cache dist
npm run build
npm test

合并前建议完成以下检查：

• 锁文件中解析到的 Webpack 确实是 5.109.1，避免工作区或间接依赖仍使用旧版本；
• 对包含动态 import()、括号表达式和代码生成插件的入口执行语法检查；
• 对 CommonJS/ESM 混合模块执行真实导出断言；
• 分别测试冷构建、缓存构建和增量构建；
• 使用懒编译时，测试开发服务器启动、动态加载和正常退出；
• 如果项目依赖自定义 Loader 或插件，保留旧版本产物作为差异比较基线。

这次升级最值得关注的不是性能数字，而是确定性：相同的模块图应该得到相同的分析结果，合法源码应该生成合法且语义稳定的 JavaScript。对于命中相关边缘场景的项目，5.109.1 是一个值得尽快验证并纳入基线的修复版本。