Rspack:字节跳动自研 Web 构建工具-基于 Rust打造高性能前端工具链

字节跳动开源了一款采用 Rust 开发的前端模块打包工具：Rspack（读音为 /'ɑrspæk/）。

据介绍，Rspack 是一个基于 Rust 的高性能构建引擎，具备与 Webpack 生态系统的互操作性，可以被 Webpack 项目低成本集成，并提供更好的构建性能。

Rspack中文文档

https://rspack.uihtm.com

特性

• 启动速度极快: 基于 Rust 实现，构建速度极快，带给你极致的开发体验。
• 闪电般的 HMR: 内置增量编译机制，HMR 速度极快，完全胜任大型项目的开发。
• 兼容 webpack 生态: 针对 webpack 的架构和生态进行兼容，无需从头搭建生态。
• 内置常见构建能力: 对 TypeScript、JSX、CSS、CSS Modules、Sass 等提供开箱即用的支持。
• 默认生产优化: 默认内置多种优化策略，如 Tree Shaking、代码压缩等等。
• 框架无关: 不和任何前端框架绑定，保证足够的灵活性。

---

从官方的描述来看，他们创建此项目并非是强行造轮子。而是当前的技术方案无法满足他们的需求，所以才决定自研 Rspack。

开发团队表示，字节跳动内部存在非常多的大型前端应用，它们有着非常复杂的构建配置，生产环境构建需要耗费十几分钟，甚至超过半小时；开发环境的耗时也超过十几分钟。

他们在 Webpack 上尝试了多种方法去优化这些项目的编译速度，但是社区内存在的方案都或多或少存在一些问题，在对这些问题总结后，他们理解到工程师对构建工具的诉求是：

• 良好的 Dev 启动性能
• 良好的 Build 性能
• 足够灵活的配置
• 生产环境的产物优化能力

在确定了这四个需求后，团队调查了社区中的所有技术方案，它们通常都能很好地满足其中个别需求，但没有一个方案能同时满足所有条件。因此，他们决定自研 Rspack。

开发团队还说道，到今天（2023 年 3 月）为止，Rspack 已经开发了 11 个月，虽然仍处于比较早期的状态，且缺失了一些 Webpack 的功能，但根据二八原则，目前的功能已经能够满足大多数项目的需求。而且根据他们的验证，Rspack 可以给项目带来 5 ～ 10 倍的编译效率提升，并且随着内置越来越多的常见 features，性能也在逐步地提升。

构建速度对比（模块数量：50000）

查看 Benchmark 详情

目前 Rspack 已经完成了 Webpack Loader 架构的支持，开发者可以在 Rspack 中使用之前见到的 Loader，如 babel-loader、less-loader、svgr 等等。团队表示长期的目标是完整支持 Loader，未来可以直接在 Rspack 中使用社区内的 vue-loader。

---

去年 Vercel 公司也开源了一款基于 Rust 的打包工具：Turbopack。Turbopack 是面向 JavaScript 和 TypeScript 优化的增量打包工具和构建系统，采用 Rust 编写，声称是 Webpack 的继任者，也是以 “高性能” 作为卖点。

Rspack 开发团队也表示他们从 Turbopack 汲取了灵感，启发了 Rspack 里基于 AST 的路径重写逻辑。

虽然 Rspack 和 Turbopack 都是基于 Rust 实现的 bundler，且都发挥了 Rust 语言的优势。但与 Turbopack 不同的是，Rspack 选择了对 Webpack 生态兼容的路线。

开发团队认为，这些兼容可能会带来一定的性能开销，但在实际的业务落地中，对于大部分的应用来说，这些性能开销是可以接受的，另一方面，这些兼容也使得 Rspack 可以更好地与上层的框架和生态进行集成，能够实现业务的渐进式迁移。

团队还提到，他们已经和 Webpack 团队确立了合作关系，Rspack 作为 Webpack 通过 Rust 进行性能优化的一个尝试，未来会和 Webpack 团队一起探索优化 Webpack 的更多可能性。当 Rspack 达到一定的成熟度时，Webpack 团队将尝试以实验特性方式将 Rspack 集成到 Webpack 中。

为什么要做 Rspack ？

字节跳动内部存在非常多的大型前端应用，它们有着非常复杂的构建配置，十几分钟甚至半小时的构建耗时，我们尝试了多种方法去优化这些项目的编译速度，但是社区内存在的方案都或多或少存在一些问题，在对这些问题总结后，我们理解到工程师对构建工具的诉求是：

• 良好的 Dev 启动性能，

  npm run dev

  是开发者每天需要运行很多次的命令，大型项目每次都需要等待 10 分钟，这对于工程师来说是非常痛苦的，所以优化 dev start 的时间是非常重要的；

• 良好的 Build 性能，

  npm run build

  是在 CI/CD 环境中经常运行的指令，它决定了应用生产交付的效率，在生产环境中有些应用经常需要 20 ～ 30 分钟的构建时间，如果能缩短这里的耗时对开发链路也会非常有帮助；

• 足够灵活的配置，用户工程的配置灵活多变，并没有做到完全的统一，在之前尝试将 Webpack 配置迁移到其他构建工具的过程中我们就遇到了非常多的问题，他们的配置都很难达到 Webpack 的灵活程度；

• 生产环境的产物优化能力，在启动 Rspack 之前，我们实践了社区内的各种方案，但是他们都面临了生产环境一定程度负优化的情况，例如拆包拆的不够精细等等。所以生产环境产物优化是我们不可舍弃的功能点。

在明确这四点之后，我们调研了社区内的所有技术方案，发现并没有完全满足我们的需求，所以我们决定自研 Rspack。

目前 Rspack 是什么阶段

到今天为止 Rspack 已经开发 11 个月左右的时间了，虽然还处于比较早期的阶段，但是在我们验证中， Rspack 可以给项目带来 5 ～ 10 倍的编译效率提升，并且随着我们内置了越来越多的常见 features，性能也在逐步的提升中。

目前 Rspack 已经完成了 Webpack Loader 架构的支持，你可以在 Rspack 中使用很多你之前见到的 Loader，如 babel-loader、less-loader、svgr 等等。我们长期的目标是完整支持 Loader，未来可以直接在 Rspack 中使用社区内的 vue-loader。

当下 Rspack 对缓存的支持还比较简单，只有内存级别的缓存，未来我们会建设更强的缓存能力，包括可以写入硬盘的缓存，并且我们会把缓存做到可以跨设备共享和迁移，提升大型应用的缓存复用率。

Rspack 作为一个较为底层的基础设施，需要通过和社区内的各种上层框架结合才能在开发中获得发挥作用，目前 Rspack 已经接入了字节内的各种研发框架，外部的合作将逐渐开始，现已与 webpack 建立正式合作关系。

未来计划

完善基础能力

Rspack 虽然目前提供的能力能够满足大多数的项目使用，但是相比 Webpack 提供的丰富能力仍然相差很多，我们在未来会根据社区反馈，丰富 Rspack 的基础能力，满足更多的构建场景需求。

跟社区内的伙伴合作

Rspack 作为一个底层依赖解决了我们自己在工作中遇到的很多问题，相信他也可以解决社区的问题。我们非常愿意给社区内的框架团队一些支持，让大家发挥出来 Rspack 真正的性能优势。

提升插件能力

目前 Rspack 已经基本支持了 Loader API，和较少的 Webpack Plugin API，有很多 API 因为会产生较大的性能问题影响，所以我们暂时没有暴露，我们同时也在探索更高性能的插件通信方案，另外一部分 API 是因为我们精力问题暂时没有完成，欢迎大家 PR。在未来，我们会考虑提供高性能的动态插件方案，这些插件可以在提供自由定制的功能的同时，带给开发者更好的开发体验。

持续提升性能

目前 Rspack 是以性能为核心卖点的项目，所以在未来我们会做很多的事情以保持这个特性，如完善性能观测实验室，做好性能防劣化的工作；在更多的场景中使用并发/多核友好的算法；研发可跨平台共享的缓存体系；优化内存占用等等。

建设质量保障体系

在保障性能的同时，我们也会努力去保障 Rspack 的质量，Webpack 已经积累了非常丰富的测试用例，未来 Rspack 会复用 Webpack 已有的测试用例来完善自己的逻辑。建设更加完善的 CI 体系，和社区项目共建 Ecosystem CI 体系，保障项目升级不对上游的项目造成break，保障项目长期健康，并且在测试覆盖率上保障长期上升。

根据我们过去使用 Webpack 的经验，升级构建工具是一件耗时耗力的操作，我们也要请大家帮助我们贡献更多的测试用例，Rspack 会在迭代中尽量保持兼容。