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 会在迭代中尽量保持兼容。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

感谢分享

谢谢分享，试用一下

谢谢分享，辛苦了

yyds。多谢分享

感谢发布原创作品，程序园因你更精彩

东西不错很实用谢谢分享

收藏一下   不知道什么时候能用到

热心回复！

感谢分享，学习下。

感谢分享，学习下。

谢谢楼主提供！

谢谢分享，辛苦了

谢谢楼主提供！

这个好，看起来很实用

热心回复！

谢谢楼主提供！

东西不错很实用谢谢分享

谢谢楼主提供！

谢谢楼主提供！