简介#

为什么选择 Rspack？#

Rspack 最初是为了解决字节跳动（一家维护许多大型单体应用程序项目并具有复杂捆绑需求的技术公司）遇到的性能问题而创建的。在某些情况下，生产环境构建时间已增长到十分钟甚至半小时，而冷启动时间可能超过几分钟。在尝试了许多捆绑器和优化思路之后，出现了一组通用的需求

• 开发模式启动性能。 npm run dev 是开发人员每小时可能调用多次的命令。如果启动时间超过 10-15 秒，工程效率就会下降。
• 快速构建。 npm run build 用于 CI/CD 管道，直接影响合并效率和应用程序交付时间。大型应用程序可能需要 20-30 分钟来运行这些管道，而捆绑时间通常是主要贡献者。
• 灵活的配置。 在尝试各种流行的捆绑器时，我们发现一刀切的配置在尝试适应现实世界项目时遇到了很多问题。webpack 的一个主要优势是其灵活性，以及轻松适应每个项目定制需求的能力。反过来，这可能会给尝试从 webpack 迁移的遗留项目带来巨大的迁移成本。
• 生产环境优化能力。 所有现有的捆绑解决方案在针对生产环境进行优化时也存在各种局限性，例如代码拆分粒度不够细，等等。Rspack 有机会从头开始重新思考这些优化，利用 Rust 特定的功能，例如多线程。

Rspack 的当前状态#

截至 2024 年 8 月，我们发布了 Rspack 1.0，现在我们认为它已经可以用于生产环境，因为它涵盖了 webpack 的大多数 API 和功能。

Rspack 目前与社区中几乎所有加载器兼容。对于 50 个下载量最高的 webpack 插件，超过 80% 可以用于 Rspack 或有替代方案。

有关 Rspack 的最新更新，请参阅 Rspack 博客。

Rspack 的未来#

虽然 Rspack 已经满足了许多项目的需要，但要达到 webpack 的全部功能，仍然存在一些差距。优先级将根据社区反馈确定，所以请告诉我们您的需求！

与社区合作伙伴的合作#

我们非常愿意为社区内的框架团队和工具链提供支持，以释放 Rspack 的真正性能优势。如果您的框架或工具链对高性能构建引擎有需求，请告诉我们！

增强插件功能#

Rspack 已经实现了完整的 Loader 接口和 webpack 插件 API 的大多数功能。虽然我们的目标不是实现插件 API 的 100% 兼容性，但我们会尽力根据社区反馈来实现主流需求。同时，我们也在探索更高性能的插件通信解决方案，以降低插件通信成本，从而确保可以实现更多插件 API。

持续改进性能#

性能是 Rspack 开发的核心卖点和重点。未来我们将探索更高性能的并发/多核友好算法、更高性能的缓存解决方案、更高性能的插件通信解决方案等。

扩展测试套件#

今天，Rspack 主要使用 webpack 测试用例的子集进行测试。未来，我们将涵盖更多这些测试，同时扩展测试套件并包含社区项目，以确保 Rspack 发布版本之间的兼容性。

与 webpack 相比#

webpack 可能是最成熟的现代捆绑器，拥有活跃的生态系统、灵活的配置和丰富的功能。

• Rust 语言效率： webpack 的竞争对手经常根据性能对其提出挑战，特别是对于大型项目。Rspack 使用 Rust 语言解决了这个问题，Rust 语言专门设计为优先考虑性能，在速度和内存管理方面都处于基准测试的顶端。Rust 还提供许多编译器保护措施，以避免其他原生语言（如 C++）常见的陷阱。

• 高度并行化的架构： webpack 受限于 JavaScript 对多线程的支持不足。相比之下，Rspack 的原生代码充分利用了现代多核 CPU。

• 内置基本捆绑功能实现： webpack 的钩子系统以其著名的功能 enable 了社区贡献的大量加载器和插件。不幸的是，这些第三方软件包经常会导致性能瓶颈，可能是因为作者对 webpack 内部机制缺乏了解，或者仅仅是因为钩子系统本身限制了算法之间的交互。Rspack 为关键功能提供内置插件，以提高性能。

• 优化的热模块替换 (HMR)： 不管您的项目有多大，确保 HMR 的良好体验都比普通的捆绑对构建时间提出了更高的要求。Rspack 采用专门的增量编译策略来解决这一需求。

与 Vite 相比#

Vite 提供了很棒的开发人员体验，但它依赖于 Rollup 进行生产环境构建，面临着与其他基于 JavaScript 的算法类似的性能成本。webpack 与 Rollup 之间的相同权衡也适用，例如缺少 optimization.splitChunks 功能的灵活性。

与 esbuild 相比#

esbuild 通过在 Golang 中实现几乎所有操作（除了某些 JavaScript 插件）来实现非常好的性能。然而，esbuild 的功能集不如 webpack 完整，例如缺少 HMR 和 optimization.splitChunks 功能。

与 Turbopack 相比#

Turbopack 与 Rspack 一样是用 Rust 编写的，但 Turbopack 从重新设计的架构和配置开始。这带来了一些好处，但对于依赖 webpack 及其庞大生态系统的项目来说，迁移成本更高。

与 Rollup 相比#

Rspack 和 Rollup 都是打包工具，但它们专注于不同的领域。Rollup 更适合打包库，而 Rspack 更适合打包应用程序。因此，Rspack 针对打包应用程序优化了许多功能，例如 HMR 和 Bundle splitting。Rollup 生成的 ESM 输出比 Rspack 更适合库。社区中还有许多工具在一定程度上封装了 Rollup，并为打包应用程序提供了更友好的支持，例如 vite 和 wmr。目前，Rspack 的生产构建性能比 rollup 更好。

与 Parcel 相比#

Rspack 的整体架构与 Parcel 有很多相似之处。例如，两者都将 CSS 资产视为一等公民，并且都支持基于过滤器的转换器。然而，Parcel 更专注于开箱即用的可用性，而 Rspack 更专注于为更高级别的框架和工具提供灵活的配置。Parcel 创新性地设计了诸如统一图和将 HTML 作为一等公民的功能。Rspack 也计划在未来支持这些功能。

下一步#

请阅读 快速入门 开始使用 Rspack。

欢迎加入 GitHub 讨论区 和 Discord 与我们交流。