2024 年 8 月 28 日
Rspack 1.0 版本现已发布!
Rspack 是基于 Rust 编写的下一代 JavaScript 打包工具, 兼容 webpack 的 API 和生态,并提供 10 倍于 webpack 的构建性能。
在 18 个月前,我们开源了 Rspack 0.1,并收到了大量来自社区的反馈和贡献。在这期间,170 位贡献者参与了 Rspack 开发,提交了超过 5000 个 pull request 和超过 2000 个 issues,帮助 Rspack 快速迭代了 80 个版本。同时,Rspack 的 npm 周下载量也突破了 10 万 🎉
今天,Rspack 终于到达了一个崭新的阶段 —— 1.0。这意味着 Rspack 已经达到生产稳定,覆盖了 webpack 绝大多数的 API 和功能,并已经做好支持更多用户的准备。
自 Rspack 开源以来,已经有众多企业和开发者在生产环境使用 Rspack,Rspack 每周的 npm 下载量也突破了 10 万。
在字节跳动内部,Rspack 的周下载量超过 40 万,有超过 1000 个 Web 应用在使用 Rspack,包括 TikTok、抖音、飞书、Coze 等。这些项目接入 Rspack 后,显著改进了构建耗时和迭代效率。这也帮助我们发现了 Rspack 早期的一些设计问题,促使我们改进架构,在迁移成本、性能和灵活性等方面做好权衡。
我们也看到更多的企业级用户开始使用 Rspack,包括微软、Amazon、阿里巴巴、Intuit、Bit.dev、Discord 等等。我们很高兴 Rspack 能够帮助这些企业用户实现渐进式迁移,也期望未来与更多的企业和开发者建立合作和交流。
自 0.1 发布以来,Rspack 推出了诸多重要的功能和优化,包括:
作为基于 Rust 实现的 Bundler,性能始终是 Rspack 的一个核心指标。从 Rspack 0.1 发布以来,我们对 Rspack 做了大量的性能改进,优化各个场景下的性能表现,并支持了 lazy compilation 等核心功能,以保障 Rspack 在大型项目中有更佳的性能。
下图是 Rspack 0.1 与 Rspack 1.0 在 benchmark 中的 build 性能对比。可以看到,Rspack 在实现大量新特性的同时,也显著提升了构建性能:
值得注意的是,Rspack 当前的架构和代码实现仍有许多优化空间。在 1.0 发布后,我们计划继续将 Rspack 的性能提升数倍 🚀,从而更好地支持大型应用开发。
在 0.1 刚发布的时候,Rspack 尚未实现许多的 webpack API 和 Hooks,只能兼容有限的 webpack 插件和 loaders,这使我们需要 fork 一些社区库来适配 Rspack,例如早期的 @rspack/plugin-html、@rspack/plugin-minify 和 @rspack/plugin-node-polyfill。
随着 API 支持的日益完善,Rspack 适配了越来越多的 webpack 插件和 loaders。目前,Rspack 已经兼容了社区几乎所有的 loader。在下载量最高的 50 个 webpack 插件 中,80% 以上都可以在 Rspack 中使用,或是找到替代方案。
在此基础上,Rspack 支持了更多的库和框架,包括 React、Preact、Vue、Solid、Svelte、NestJS 等。我们也感谢社区众多插件的维护者主动适配 Rspack,如 unplugin 和 node-polyfill-webpack-plugin 等。这里尤其要感谢 Alexander Akait,他作为 webpack 的主要维护者之一,帮助我们支持了许多 webpack loaders 和插件。
我们也期望未来能够支持和创造更多的社区插件,使 webpack 和 Rspack 的生态更加繁荣。
生产构建的包体积一直是 Rspack 最为关注的核心指标。自 0.1 发布以来,Rspack 逐步对齐了 webpack 的各个产物优化能力,实现了完整的 split chunks、tree shaking、scope hoisting、mangle exports 等重要特性。
当一个项目从 webpack 迁移到 Rspack 后,这些优化能够保障,在提升开发体验的同时,产物的包体积仍与 webpack 处于同一水平。在部分场景下,Rspack 的产物体积已经略优于 webpack。
例如,我们在一个真实的中型 web 应用中进行验证,与 Rspack 0.1 相比,Rspack 1.0 的产物体积从 6600KB 优化至 5900KB,与 webpack 持平。未来,Rspack 也会继续探索更先进的包体积优化方案。
Module Federation 是一种 Micro-Frontend 架构模式,在前端生态中得到广泛应用。Rspack 团队和 Module Federation 团队一起合作开发了 Module Federation 2.0。新版本提供了动态 TS 类型提示、Runtime 插件机制、devtools、平台部署协议等功能,使得 Module Federation 可以更好地支持基于微前端架构的大型应用。
此外,Rspack 也保留着对 Module Federation 1.0 的兼容和支持,使 webpack 项目能够更轻松地迁移。
在 1.0 中,我们改进了 configuration、JavaScript API、plugin API 的稳定性,这保证了上层的工具和框架能够更加轻松地与 Rspack 集成。同时,我们还完善了官网的指南和 API 文档。
Rspack 1.0 还包含一个全新的文档首页,感谢设计师 Emily Jackson 和团队成员 Zack Jackson 为此付出的努力。
近两年,社区中涌现出多个基于 Rust 的 bundler,它们的性能表现都相当优异。Rspack 在确保卓越性能的同时,也在灵活度、兼容性等方面做到了社区领先。
Rspack 当前的目标是:
Rstack 是 "Rspack Stack" 的缩写,代表以 Rspack 为核心的一整套技术栈,包含以下工具:
这些工具共同构成了 Rstack 技术栈。我们希望通过提供统一的 web 开发工具,为开发者和用户带来一流的体验。
Rspack 1.0 是对标 webpack v5 设计的,这帮助了大量使用 webpack 的项目平滑地迁移到 Rspack。在兼容 webpack 的同时,Rspack 1.0 也在拥抱现代 Web 标准、追求极致的构建性能:
在 Rspack 未来的 major 版本中,将基于 webpack API 进行演进,使其更符合现代 web 开发的需求。
如果你正在使用 Rspack 0.7 或更早的版本,请留意 1.0 版本包含一些不兼容更新,为此我们准备了详细的文档来帮助升级,请参考:从 Rspack 0.x 迁移。
如果你还未使用过 Rspack,请参考 快速上手 来接入 Rspack,也欢迎为 Rspack GitHub 仓库 点亮一颗 Star 🌟。
Rspack 1.0 是一个全新的起点,在本次发布后,Rspack 团队将聚焦于以下目标:
下面是一些我们计划在 Rspack 1.x 支持的关键能力:
Rspack 目前能够满足大部分项目的性能诉求,但是仍然存在较大的性能优化空间。在开发环境,Rspack 内部的 make 阶段已经实现了接近常量级别的增量构建,在 seal 阶段仍然有一些计算会随着项目规模的增加而变慢。未来 Rspack 会对 seal 阶段的各个计算进行增量化改造,从而将 HMR 耗时控制在常量级别。
Rspack 缓存能力的演进路线,是依次实现 memory cache、persistent cache 和 portable cache。目前 Rspack 已经实现了 memory cache,它带来了出色的 HMR 性能。下一步,我们将在此基础上实现 persistent cache ,这将解决大型项目冷启动耗时较长的问题,功能上对齐 webpack。
在这之后,我们计划进一步实现 portable cache,这意味着 Rspack 的构建缓存不仅是持久化的,同时也可以被移植到任何不同的环境和机器,这将帮助团队更好地利用缓存,并为分布式构建奠定基础。
目前 Rspack 在处理 TypeScript 模块时,会先通过 loader 将其转换为 JavaScript 再处理。这虽然提供了充足的灵活性,但是也阻碍了进一步的产物优化。 例如,开发者需要使用 enum
替代 const enum
,但是 enum
本身难以进行常量优化,未来我们考虑重新将 TypeScript 作为 Rspack 的一等公民,充分利用 TypeScript 的静态信息,提供更高级的编译产物优化(如 基于 type 的 property renaming)。
目前,上层工具可以使用 JS API 来集成 Rspack,这提供了良好的扩展性。但是 Rust 和 JavaScript 存在通信开销,这在一定程度上限制了 Rspack 的性能。我们也提供了 SWC Wasm plugin 以支持扩展,但是 Wasm 的性能相比 native 语言仍然有一定差距,为了给上层工具提供更灵活的接入方式和更好的性能,我们计划开放 Rspack 的 Rust API 用于集成。
在字节跳动内部,我们已经基于 Rspack 实验性地支持了 RSC(React Server Components),并在一个大型 web 项目中得到验证。未来 Rspack 将会为 RSC 提供一等公民的支持,提供更多的核心能力来帮助实现 RSC。例如,目前 Rspack 已经支持 layer 特性,能够在单次打包时构建出多种环境的产物。
ESM 是 JavaScript 模块的标准,目前,我们正在改进 Rspack 和 webpack 对 ESM 产物的支持,并实现基于 Rspack 的 library 构建工具—— Rslib。这将帮助开发者更好地使用 Rspack 来构建 npm 包,并享受 ESM 带来的静态分析能力和 tree shaking 支持。
Rspack 的发展离不开广大的社区贡献者和社区伙伴,这里特别要感谢:
在开源社区上,Rspack 获得了 2024 年度 Breakthrough of the Year 奖项,这对于 Rspack 团队是一个很大的鼓舞,感谢所有投票支持 Rspack 的开发者:
自 0.1 发布后,我们和社区的多个团队建立了深入的合作关系。例如:
同时我们也很欣喜地看到,Rspack 正在被应用或集成到更广泛的生态上,包括 Bazel、Storybook、Electron 等。
最后,再次感谢所有为 Rspack 生态贡献过的开发者 ❤️:
1.0 的发布,意味着 Rspack 实现了 webpack 的核心功能,API 达到稳定。在未来 12~18 个月内,我们会保证 Rspack 1.x API 的稳定性,开发者可以放心地基于 Rspack API 开发上层的框架和工具。在 1.x 的迭代期间,我们仍然可能会发现一些 Rspack 不合理的设计,我们将通过 future flags 的方式,实现渐进式地升级。
我们正在进行 Rsbuild 1.0 发布的准备工作,并计划于 9 月上旬正式发布。
在发布 Rspack 1.0 的同时,我们也已经发布了 Rsbuild 1.0 RC 版本,后续 Rsbuild 将不再引入不兼容更新。请参考 从 Rsbuild 0.x 迁移 升级到 Rsbuild 1.0 RC。
Rspack 遵循语义化版本(semver),不会在 minor 或 patch release 中引入 public API 的不兼容变更,注意有以下一些特例:
如果你的项目对语义化版本有着严格的要求,可以将 Rspack 固定到 minor 版本。
Rspack 提供了一些实验性特性,这些特性可以通过 experiments 配置项使用。在 minor release 中,Rspack 可能对这些实验性特性的 public API 做一些调整,并在更新日志中对这些变动进行详细的说明。因此,如果你使用了实验性特性,请留意 minor 版本的更新日志。
Rspack 基于 SWC 实现,而 SWC 目前处于 pre-1.0 阶段。为了及时地跟进 SWC 的修复和优化,我们会定期升级 SWC 版本,这可能会包含 SWC 的一些不兼容变更,或是导致低版本的 SWC Wasm 插件不可用。在这种情况下,如果 SWC 升级包含 breaking change,我们会发布 Rspack 的 minor 版本,并在更新日志中说明,;如果 SWC 升级不包含 breaking change,我们可能会发布在 Rspack 的 patch 或者 minor 版本。
在 minor 版本中,Rspack 导出的类型可能会发生变化,这是因为:
如果在 Rspack 之前版本中错误地实现了 webpack 的 API,那么我们可能在非 major 版本进行修复,并对齐 webpack API 的行为。