路线图
这里将持续记录 Rspack 与 Rstack 工具链的最新规划与进展，内容会随版本演进而更新。
更新时间：2025-10
Rspack 2.0
我们正在开发 Rspack 2.0 与 Rsbuild 2.0，这一版本的重点在于改进 API 和内部架构、提升性能，进一步拥抱现代 Web 标准，并提供更优秀的开发体验。
主要方向包括：
- 精简产物与 API：在兼容 webpack 的基础上，重新设计产物结构与 webpack 特有 API，使之更直观和简洁。
- 改进 ESM 输出：提供更完善的 ESM 支持，并通过 Rsbuild 与 Rslib 提供即开即用的体验。
- 内置 RSC 支持：借鉴 Parcel 等工具的经验，提供开箱即用的 React Server Components 支持。
- 更稳定的持久化缓存：改进持久化缓存的可用性与稳定性，计划在开发模式下默认启用。
- 启用 Native Watcher：通过原生的文件监听实现，来缩短文件变更的响应时间，提升 HMR 性能。
- 优化核心架构：优化核心架构和数据流，减少内存开销、提升性能与可维护性。
- 迁移至纯 ESM 包：将现有的 npm 包改造为 pure ESM 格式，并不再支持 Node.js 18。
- 更多...
首个预览版本计划于 2026 年 2 月 发布，我们将谨慎评估每一项破坏性变更，以提供平滑的升级路径。
欢迎在此参与 breaking changes 的讨论与反馈：👉 discussions/9270
Rstack 工具链
我们正在打造以 Rspack 为核心的 JavaScript 统一工具链 —— Rstack。
目前 Rstack 的各个工具主要聚焦于以下目标：
- Rsbuild：与 Rspack 同步开发 2.0 版本，聚焦于性能和开发体验改进。
- Rslib：集成 Rspack 新版 ESM 方案，计划在 API 稳定后发布 1.0 正式版。
- Rsdoctor：通过 MCP 加强对 AI Agent 的支持，并新增 tree shaking 分析等功能。
- Rspress：正在开发 2.0 版本，将带来架构、UI 和功能层面的全面改进。
- Rstest：持续完善测试能力，支持 browser mode，改进 VS Code 插件，详见 Rstest Roadmap。
可移植的缓存
Rspack 的缓存系统正逐步演进，从内存缓存（memory cache）到持久化缓存（persistent cache），并正积极探索远端缓存（可移植的缓存）的实现方案。
这一方向旨在让构建缓存能够在不同的机器和环境之间共享，帮助团队减少重复构建的开销，提升构建效率。
改进 ESM 支持
我们正在改进 Rspack 的 ESM 输出，并通过 Rslib 提供开箱即用的库开发体验。这将帮助开发者更好地使用 Rspack 来构建 npm 包，并享受 ESM 带来的静态分析能力和 tree shaking 支持。
与此同时，我们也在完善 Rspack 对 Web 应用的 ESM 支持，允许应用以原生 ESM 的方式运行在现代浏览器环境中。
改进性能
性能始终是 Rspack 的核心关注点。我们正在持续优化内部实现，包括探索更高效的并发与调度方式、更好的缓存机制、更低开销的插件通信方案以及各种微优化。
社区合作
Rspack 已经帮助我们在实践中解决了诸多性能与效率问题，我们也希望它能为更广泛的社区带来价值。我们非常期待能与社区内的框架团队深入合作，如果你的框架或者工具链对与 Rspack 合作感兴趣，欢迎与我们联系以获取进一步的支持。
webpack 兼容性
webpack 拥有庞大而多样的 API，Rspack 将以渐进式的方式逐步完善兼容性。我们会根据社区反馈的优先级，支持使用频率较高的 loaders 和 plugins，确保生态的平稳迁移与良好体验。
使用 Rust 扩展 Rspack
目前，上层工具和框架可以使用 JavaScript API 来集成 Rspack，这提供了良好的扩展性。但是 Rust 和 JavaScript 存在通信开销，这在一定程度上限制了 Rspack 的性能。
我们正在完善使用 Rust 扩展 Rspack 的方案，消除跨语言通信的开销，参考 Rspack 1.5 博客。