docs: update roadmap

website/docs/en/misc/planning/roadmap.mdx

@@ -1,70 +1,52 @@
----
-description: 'provides an overview of the latest plans and progress for Rspack and the Rstack toolchain'
----
-
 # Roadmap
 
-This document provides an overview of the latest plans and progress for Rspack and the Rstack toolchain. It will be continuously updated as new versions are released.
-
-> Last updated: 2025-10
-
-## Rspack 2.0
+This document outlines the current direction of Rspack and will continue to evolve alongside future releases.
 
-We are developing Rspack 2.0 and Rsbuild 2.0, focusing on API and internal architecture improvements, performance optimization, adoption of modern web standards, and a better developer experience.
+> Last updated: 2026-04
 
-Key areas include:
+## Advanced output optimization
 
-- **Streamlined outputs and APIs**: Redesigning output structure and webpack-specific APIs for better clarity and simplicity, while maintaining compatibility.
-- **Improved ESM output**: Enhancing ESM support and providing an out-of-the-box experience through Rsbuild and Rslib.
-- **Built-in RSC support**: Inspired by tools like Parcel, offering built-in support for React Server Components.
-- **More stable persistent cache**: Improving usability and reliability of persistent cache, with plans to enable it by default in development mode.
-- **Enable Native watcher**: Using native watcher to reduce rebuild latency and improve HMR performance.
-- **Core architecture optimization**: Refining the internal data flow to reduce memory usage and improve performance and maintainability.
-- **Migration to pure ESM packages**: Converting all npm packages to pure ESM format and dropping Node.js 18 support.
-- And more...
+Rspack prioritizes stable output behavior in its default optimization pipeline. In areas such as side effects analysis, it intentionally takes a conservative approach. This trade-off works well for most projects, but there is still room to push optimization further in scenarios where bundle size matters most.
 
-The first preview release is planned for **February 2026**. We will carefully review every breaking change to ensure a smooth upgrade path.
+Rspack already supports fine-grained optimizations based on pure annotations. Going forward, we will continue improving tree shaking and provide optimization controls with clearer boundaries and more explicit trade-offs, so users can choose the level of optimization that best fits their needs.
 
-> Join the discussion on breaking changes here: 👉 [discussions/9270](https://github.com/web-infra-dev/rspack/discussions/9270)
+We also plan to incorporate more static type information into optimization analysis, drawing on ideas from projects such as Prepack, Closure Compiler, and React Compiler. The goal is to bring more optimization-relevant signals from source code into the bundling pipeline.
 
-## Rstack toolchain
+For code splitting, we will continue exploring finer-grained strategies. Today, the smallest practical unit of splitting is still usually the module, which means partially reused modules can still introduce unnecessary loading. We plan to explore approaches inspired by tools such as esbuild and Turbopack, including module-level partitioning based on actual reuse patterns, while keeping cache stability, debugging experience, and runtime behavior predictable. We will also explore new loading strategies alongside emerging module capabilities such as `import defer`.
 
-We are building a unified JavaScript toolchain centered around Rspack — [Rstack](/guide/start/ecosystem#rstack).
+## Improving build performance
 
-The main focus areas across Rstack tools include:
+Rspack will continue improving its core algorithms, data structures, and incremental build paths. In real-world projects, however, bottlenecks are often not limited to the bundling pipeline itself. They also come from surrounding tools such as linters, type checkers, and Tailwind CSS.
 
-- Rsbuild: Developing 2.0 alongside Rspack, focusing on performance and developer experience.
-- Rslib: Integrating Rspack's new ESM output, aiming for a 1.0 release once the APIs stabilize.
-- Rsdoctor: Expanding AI Agent support via MCP and adding new features such as tree-shaking analysis.
-- Rspress: Developing v2.0 with major architecture, UI, and feature improvements.
-- Rstest: Enhancing testing capabilities with browser mode and VS Code extension. See the [Rstest Roadmap](https://github.com/web-infra-dev/rstest/issues/85) for details.
+For that reason, our performance work will not focus only on the Rspack core. We will continue improving related tools across the Rstack ecosystem as well. For example, in Rslint we are exploring linting and type checking based on tsgo as an alternative to the common `eslint-webpack-plugin` and `fork-ts-checker-webpack-plugin` combination, with the goal of improving the performance of the overall build pipeline.
 
-## Remote cache
+## Support for agents
 
-Rspack's caching system is evolving from memory cache to persistent cache, and we are actively exploring remote cache (portable cache).
+More developers are already using coding agents for bundling-related tasks such as performance analysis, output optimization, and automated migration. We have started supporting these workflows through [Rstack Skills](https://github.com/rstackjs/agent-skills). At the same time, it has become increasingly clear that effective AI-assisted problem solving in bundling depends on three things: access to accurate context, reliable reproduction of issues, and fast, low-cost hypothesis validation.
 
-This effort aims to make build caches shareable across different machines and environments, helping teams reduce redundant builds and improve efficiency.
+Going forward, this work will focus on four areas:
 
-## Enhanced ESM support
+- Improving debugging capabilities so coding agents can investigate issues with Rspack debug builds and connect compile-time information with runtime behavior.
+- Improving diagnostic output by exposing more machine-readable compilation data, including bailout reasons in optimization stages such as tree shaking and scope hoisting, as well as module, chunk, and plugin pipeline information for automated analysis.
+- Improving context collection and issue reproduction by exposing resolved configuration results, environment details, and key compilation paths, so AI-generated suggestions can be reproduced and verified more reliably.
+- Shortening the feedback loop by exploring more efficient compilation modes for agent-driven workflows, reducing the cost of iterative validation.
 
-We are improving Rspack's ESM output and providing a seamless library-building experience through Rslib. This enables developers to build npm packages with better static analysis and tree-shaking support.
+## More modern output formats
 
-In parallel, we're extending Rspack's ESM capabilities for web applications, enabling applications to run natively as ESM in modern browsers.
+Rspack has historically maintained compatibility with webpack’s output formats. This is important for migration correctness and ecosystem compatibility, but it also means carrying forward some historical design constraints. Supporting formats such as CJS, UMD, and ESM alongside runtime features such as HMR and Module Federation often forces traditional bundlers to trade off readability against how well generated code can be analyzed by downstream tools.
 
-## Performance improvements
+Looking ahead, while preserving key runtime capabilities, we will continue exploring more modern output forms, including cleaner ESM output and organizational patterns based on emerging standards such as import maps and module fragments.
 
-We are continuously optimizing internal implementations — exploring more efficient concurrency models, better caching strategies, lower-overhead plugin communication, and various micro-optimizations.
+## Keeping up with community standards and platform capabilities
 
-## Community collaboration
-
-Rspack has helped us solve many performance and efficiency challenges in real-world projects. We hope it can bring similar value to the broader community. We welcome collaborations with framework and tooling teams interested in Rspack integration — feel free to reach out for support.
+The JavaScript ecosystem continues to evolve, and new syntax, module capabilities, and runtime APIs keep maturing. Rspack will continue to follow these changes closely, including support for features such as `import.meta` and `import defer`.
 
-## Webpack compatibility
+## Supporting higher-level frameworks
 
-Webpack provides a rich and diverse API. Rspack takes a progressive approach to compatibility, prioritizing high-usage loaders and plugins based on community feedback to ensure a smooth migration experience.
+Modern bundlers are no longer only responsible for turning modules into bundles. For frameworks and higher-level tooling, they increasingly need to handle responsibilities such as multi-environment compilation, server/client boundary analysis, style and asset collection, and runtime coordination.
 
-## Extending Rspack with Rust
+Rspack already provides experimental support for React Server Components. Going forward, we will continue turning more of these capabilities into stable foundational primitives, reducing the integration cost for higher-level frameworks and tools while lowering the amount of adapter code they need to maintain.
 
-Currently, higher-level tools and frameworks can integrate Rspack through its [JavaScript API](/api/javascript-api/index), which offers good extensibility. However, Rust-to-JavaScript communication introduces some overhead and limits performance.
+## Community collaboration
 
-We are developing a Rust extension system for Rspack to eliminate cross-language overhead. For more details, see the [Rspack 1.5 blog](/blog/announcing-1-5#extending-rspack-with-rust).
+Rspack has already helped address many performance and efficiency problems in practice, and we hope it can continue to be useful to a broader range of projects. We look forward to deeper collaboration with framework and tooling teams across the ecosystem. If your framework or toolchain is interested in working with Rspack, feel free to reach out.

website/docs/zh/misc/planning/roadmap.mdx

@@ -4,67 +4,53 @@ description: '我们正在开发 Rspack 2.0 与 Rsbuild 2.0，这一版本的重
 
 # 路线图
 
-这里将持续记录 Rspack 与 Rstack 工具链的最新规划与进展，内容会随版本演进而更新。
+这里将持续记录 Rspack 的最新规划与进展，内容会随版本演进而更新。
 
-> 更新时间：2025-10
+> 更新时间：2026-04
 
-## Rspack 2.0
+## 进阶的产物优化
 
-我们正在开发 Rspack 2.0 与 Rsbuild 2.0，这一版本的重点在于改进 API 和内部架构、提升性能，进一步拥抱现代 Web 标准，并提供更优秀的开发体验。
+Rspack 在默认优化上会优先保证产物行为的稳定性，尤其在 side effects 判断等环节会采取保守策略。这种取舍适合大多数项目，但在追求极致体积的场景下，仍有继续优化的空间。
 
-主要方向包括：
+Rspack 已支持基于 pure annotation 的细粒度优化。后续我们会继续加强 tree shaking，并提供边界清晰、可分级的优化配置，使用户可以根据场景在默认安全性与优化激进程度之间进行选择。
 
-- **精简产物与 API**：在兼容 webpack 的基础上，重新设计产物结构与 webpack 特有 API，使之更直观和简洁。
-- **改进 ESM 输出**：提供更完善的 ESM 支持，并通过 Rsbuild 与 Rslib 提供即开即用的体验。
-- **内置 RSC 支持**：借鉴 Parcel 等工具的经验，提供开箱即用的 React Server Components 支持。
-- **更稳定的持久化缓存**：改进持久化缓存的可用性与稳定性，计划在开发模式下默认启用。
-- **启用 Native Watcher**：通过原生的文件监听实现，来缩短文件变更的响应时间，提升 HMR 性能。
-- **优化核心架构**：优化核心架构和数据流，减少内存开销、提升性能与可维护性。
-- **迁移至纯 ESM 包**：将现有的 npm 包改造为 pure ESM 格式，并不再支持 Node.js 18。
-- 更多...
+我们也会结合静态类型信息继续完善优化分析，借鉴 Prepack、Closure Compiler 和 React Compiler 的相关思路，将源代码中可用于优化的信息进一步引入打包流程。
 
-首个预览版本计划于 **2026 年 2 月** 发布，我们将谨慎评估每一项破坏性变更，以提供平滑的升级路径。
+在代码拆分方面，后续会继续推进更细粒度的拆分策略。当前的 code splitting 最小粒度通常仍是模块，模块内部的局部复用仍可能带来额外加载。接下来，我们会参考 esbuild、Turbopack 等工具在 module splitting 方向上的经验，基于实际复用关系将公共模块拆分为更小的单元，在保证缓存稳定性、调试体验和运行时行为可控的前提下，尽量减少不必要的加载。同时，我们也会结合 `import defer` 等模块能力，探索新的加载策略。
 
-> 欢迎在此参与 breaking changes 的讨论与反馈：👉 [discussions/9270](https://github.com/web-infra-dev/rspack/discussions/9270)
+## 提升构建性能
 
-## Rstack 工具链
+Rspack 会继续优化自身的算法、数据结构和增量构建路径。但在真实项目中，性能瓶颈并不总在打包主流程本身，很多时候会出现在 linter、type checker、Tailwind CSS 等配套工具上。
 
-我们正在打造以 Rspack 为核心的 JavaScript 统一工具链 —— [Rstack](/guide/start/ecosystem#rstack)。
+因此，后续的性能工作不会只聚焦于 Rspack 内核。我们也会继续推进 Rstack 生态中相关工具的演进，例如在 Rslint 中探索基于 tsgo 的 lint 和 typecheck 方案，作为当前常见的 `eslint-webpack-plugin` 与 `fork-ts-checker-webpack-plugin` 组合的替代选择，从而改善整个构建链路的性能表现。
 
-目前 Rstack 的各个工具主要聚焦于以下目标：
+## 对 agent 的支持
 
-- 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](https://github.com/web-infra-dev/rstest/issues/85)。
+越来越多开发者已经开始使用 coding agent 处理构建相关问题，包括性能分析、产物优化和自动化迁移。我们已经通过 [Rstack Skills](https://github.com/rstackjs/agent-skills) 为这类工作提供了一定支持。与此同时，我们也逐渐明确，AI 是否能够有效解决构建问题，很大程度上取决于三个前提：是否能够获得准确的上下文，是否能够稳定复现问题，以及是否能够以较低成本快速验证假设。
 
-## 可移植的缓存
+接下来，这部分工作会主要围绕四个方向展开：
 
-Rspack 的缓存系统正逐步演进，从内存缓存（memory cache）到持久化缓存（persistent cache），并正积极探索远端缓存（可移植的缓存）的实现方案。
+- 完善调试能力，使 coding agent 可以基于 Rspack 的调试版本排查问题，并建立编译期与运行时信息之间的关联。
+- 完善诊断信息，在编译阶段暴露更多可被机器消费的过程数据，例如 tree shaking、scope hoisting 等优化阶段的 bailout reason，以及模块、chunk 和插件链路信息，用于自动分析和迭代优化。
+- 完善上下文采集与问题复现能力，例如暴露配置解析结果、环境信息和关键编译路径，使 AI 生成的建议具备复现和验证条件。
+- 缩短反馈闭环，面向 agent 场景探索效率更高的编译模式，降低“提出假设、执行验证、继续迭代”的成本。
 
-这一方向旨在让构建缓存能够在不同的机器和环境之间共享，帮助团队减少重复构建的开销，提升构建效率。
+## 现代化的产物格式
 
-## 改进 ESM 支持
+过去，Rspack 一直保持对 webpack 产物格式的兼容。这对于迁移正确性和生态兼容都很重要，但也意味着需要继承一部分历史设计。为了同时支持 CJS、UMD、ESM 等不同输出格式，以及 HMR、Module Federation 等运行时能力，传统打包工具的产物往往需要在可读性与二次静态分析能力之间做出取舍。
 
-我们正在改进 Rspack 的 ESM 输出，并通过 Rslib 提供开箱即用的库开发体验。这将帮助开发者更好地使用 Rspack 来构建 npm 包，并享受 ESM 带来的静态分析能力和 tree shaking 支持。
+未来，我们会在保留关键运行时能力的前提下，继续探索更现代的产物形态，例如更纯净的 ESM 输出，以及基于 import maps、module fragments 等新标准的组织方式。
 
-与此同时，我们也在完善 Rspack 对 Web 应用的 ESM 支持，允许应用以原生 ESM 的方式运行在现代浏览器环境中。
+## 跟进社区规范与平台能力
 
-## 改进性能
+JavaScript 社区仍在持续演进，新的语法、模块能力和运行时接口也在不断成熟。Rspack 会持续跟进这些变化，例如对 `import.meta` 和 `import defer` 的支持。
 
-性能始终是 Rspack 的核心关注点。我们正在持续优化内部实现，包括探索更高效的并发与调度方式、更好的缓存机制、更低开销的插件通信方案以及各种微优化。
+## 支持上层框架
 
-## 社区合作
-
-Rspack 已经帮助我们在实践中解决了诸多性能与效率问题，我们也希望它能为更广泛的社区带来价值。我们非常期待能与社区内的框架团队深入合作，如果你的框架或者工具链对与 Rspack 合作感兴趣，欢迎与我们联系以获取进一步的支持。
-
-## webpack 兼容性
+今天的打包工具已经不只是将模块打成捆绑包的工具。对于框架和上层工具来说，它还需要承担多环境编译、服务端与客户端边界分析、样式与资源收集、运行时协调等底层职责。
 
-webpack 拥有庞大而多样的 API，Rspack 将以渐进式的方式逐步完善兼容性。我们会根据社区反馈的优先级，支持使用频率较高的 loaders 和 plugins，确保生态的平稳迁移与良好体验。
+Rspack 已经为 React Server Components 提供了实验性支持。接下来，我们会继续将更多能力沉淀为稳定的基础能力，降低上层框架和工具的接入成本，并减少适配代码。
 
-## 使用 Rust 扩展 Rspack
-
-目前，上层工具和框架可以使用 [JavaScript API](/api/javascript-api/index) 来集成 Rspack，这提供了良好的扩展性。但是 Rust 和 JavaScript 存在通信开销，这在一定程度上限制了 Rspack 的性能。
+## 社区合作
 
-我们正在完善使用 Rust 扩展 Rspack 的方案，消除跨语言通信的开销，参考 [Rspack 1.5 博客](/blog/announcing-1-5#使用-rust-扩展-rspack)。
+Rspack 已经帮助我们在实践中解决了诸多性能与效率问题，我们也希望它能为更广泛的社区带来价值。我们非常期待能与社区内的框架团队深入合作，如果你的框架或者工具链对与 Rspack 合作感兴趣，欢迎与我们联系以获取进一步的支持。