Rspack 2.0：用纯 ESM 核心、更少依赖和静态分析换取更快构建

2026-07-21 29 预计阅读时间: 1 分钟
来源: infoq.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：8 分钟

Rspack 2.0 的变化不只是“构建更快”。这个由字节跳动开发的构建工具正在同时收紧三个关键边界：核心转向纯 ESM、减少依赖数量、强化静态分析，并开始支持 React Server Components（RSC）。这意味着升级时既能获得性能收益，也需要重新检查配置文件、插件和 Node.js 工具链是否仍依赖 CommonJS。

纯 ESM 核心改变了什么

纯 ESM 核心让 Rspack 更贴近现代 JavaScript 生态。对构建工具而言，这不只是把 require() 改成 import：模块边界变得更明确，也为静态分析、按需加载和依赖裁剪提供了更稳定的基础。

实际迁移中，最容易暴露问题的是项目外围代码，例如：

  • rspack.config.js 中直接使用 require()；
  • 内部插件仍以 CommonJS 方式加载 Rspack API；
  • 配置依赖 __dirname、__filename 等 CommonJS 全局变量；
  • 脚本通过 require() 同步加载一个纯 ESM 包。

因此，升级不能只改 package.json 中的版本号。需要把构建配置也视为应用代码，纳入类型检查、代码审查和持续集成。

更少依赖为什么值得关注

构建工具位于供应链上游，每增加一个传递依赖，都可能增加安装时间、版本冲突和安全审计成本。Rspack 2.0 强调精简依赖，直接收益包括更轻的安装树，以及更小的依赖治理范围。

可以在升级前后保存依赖快照，避免只凭主观感受判断：

npm ls --all > deps-before.txt
npm install --save-dev @rspack/core@2 @rspack/cli@2
npm ls --all > deps-after.txt

diff -u deps-before.txt deps-after.txt || true
npm audit

这里需要观察的不只是依赖总数，还包括是否出现重复版本、失效的 peer dependency，以及内部插件是否锁定了旧版 Rspack API。

静态分析增强同样与依赖精简有关。构建器越能准确理解 import、export 和条件分支，就越有机会排除不可达代码。不过，动态模块路径、运行时拼接的导入表达式和带副作用的包仍可能限制优化空间。

可以这样迁移一个最小项目

下面是一个可以直接运行并继续改造的最小 ESM 项目。运行前确认当前 Node.js 版本满足 Rspack 2.0 的正式要求，并根据项目实际情况调整入口和目标环境。

package.json：

{
  "name": "rspack-2-esm-demo",
  "private": true,
  "type": "module",
  "scripts": {
    "build": "rspack build",
    "dev": "rspack serve"
  },
  "devDependencies": {
    "@rspack/cli": "^2.0.0",
    "@rspack/core": "^2.0.0"
  }
}

rspack.config.mjs：

import path from "node:path";
import { fileURLToPath } from "node:url";

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

export default {
  mode: process.env.NODE_ENV === "production" ? "production" : "development",
  entry: "./src/index.js",
  output: {
    path: path.resolve(__dirname, "dist"),
    filename: "app.js",
    clean: true
  }
};

src/index.js：

const features = ["ESM core", "static analysis", "leaner dependencies"];

document.body.innerHTML = `
  <main>
    <h1>Rspack 2.0 demo</h1>
    <ul>${features.map((item) => `<li>${item}</li>`).join("")}</ul>
  </main>
`;

安装并构建：

npm install
npm run build
ls -lh dist/app.js

如果现有仓库不能整体设置 "type": "module"，可以只把配置命名为 rspack.config.mjs，逐步迁移构建层，避免立即改变所有 .js 文件的模块语义。

性能提升要在自己的仓库里验证

公开基准显示 Rspack 2.0 的构建时间有明显改善，但构建器性能高度依赖模块数量、缓存状态、loader、插件以及文件系统。升级评估至少应分开测量冷构建、热构建和开发模式增量重编译。

可以先用简单脚本收集冷构建数据：

rm -rf dist node_modules/.cache
/usr/bin/time -p npm run build

rm -rf dist node_modules/.cache
/usr/bin/time -p npm run build

rm -rf dist node_modules/.cache
/usr/bin/time -p npm run build

更严谨的做法是在相同机器、Node.js 版本和锁文件条件下多次执行，记录中位数，并同步比较产物大小和运行结果。速度提升不能以错误的 tree shaking、缺失资源或 source map 退化为代价。

RSC 支持则值得 React 全栈团队关注，但不要把“支持 RSC”理解成现有应用可以无配置切换。RSC 涉及服务端与客户端模块边界、框架集成和部署运行时，应优先按照所用框架的适配状态进行验证，而不是直接拼装底层能力。

升级前的检查清单

Rspack 每周 npm 下载量已超过 500 万，说明它已经进入大量真实工程。采用范围扩大之后，2.0 的性能和架构变化更有价值，但兼容性回归的影响面也更大。

升级时建议完成以下检查：

  • 确认 Node.js、@rspack/core、CLI 和框架适配层的版本要求；
  • 搜索配置及插件中的 require()、module.exports、__dirname 和 __filename；
  • 对比冷构建、增量构建、产物体积和 source map；
  • 审计 loader、插件和内部构建脚本的兼容性；
  • 为浏览器产物和服务端产物各执行一次冒烟测试；
  • 在小型应用或单个工作区先升级，再逐步扩展到 monorepo。

Rspack 2.0 最值得采用的地方，不是某一个孤立的基准数字，而是它把性能、模块系统和依赖治理放进了同一次架构升级。对已经使用 Rspack 的团队，这是一次需要认真测试的升级；对仍受大型 Webpack 工程构建时间困扰的团队，它也提供了一个更成熟的评估节点。

# AI # InfoQ # 全栈

相关推荐