Rspack brainstorm meeting notes (2024-07) #7405
Replies: 4 comments 1 reply
-
|
Bet on Rstack <3 |
Beta Was this translation helpful? Give feedback.
-
|
I am super bullish on Rstack! |
Beta Was this translation helpful? Give feedback.
-
|
可移植的持久化缓存 目前webpack做增量更新时比较鸡肋（缓存命中率相当低） |
Beta Was this translation helpful? Give feedback.
-
|
Could you provide an approx. date for when the Portable Persistent Cache will be available, please? |
Beta Was this translation helpful? Give feedback.
-
|
We plan to launch persistent cache in Q4 |
Beta Was this translation helpful? Give feedback.
-
English version
The Rspack team held an offline brainstorming meeting in July 2024. We discussed solutions to some key current issues and envisioned the future development direction of Rspack and its ecosystem.
This document summarizes some of the key topics discussed at the meeting to help Rspack contributors and users understand the roadmap of Rspack.
A term for Rspack tool stack
We have developed a number of powerful tools based on Rspack, including Rsbuild, Rspress, Rsdoctor, Rslib (coming soon) and Rspeedy (coming soon).
At this meeting, we voted to use the term "Rstack" to collectively refer to these Rspack-based tools (we used to call them "Rsfamily"). "Rstack" is a combination of "Rs" and "Stack", representing a comprehensive technology stack built around Rspack.
Relationship between Rspack 2.0 and webpack
Rspack 1.0 has been designed to be compatible with webpack v5, which has allowed many projects using webpack to migrate smoothly to Rspack. However, this is a double-edged sword. Compatibility with webpack has constrained the design of Rspack, preventing Rspack from achieving optimal solutions in terms of API, architecture, output format, and build performance.
Future major releases of Rspack will gradually introduce some breaking changes compared to webpack v5 (Rspack 2.0 will be what we think webpack v6 should be like). This will help Rspack improve its API design, further improve build performance, and allow the implementation of more powerful new features.
We will also continue to improve Rsbuild, providing more modern APIs and configurations through Rsbuild, reducing the learning curve for users and plugin developers.
Rspack 2.0 is planned to be released about 12 to 18 months after the release of Rspack 1.0.
TypeScript-based optimization
Rspack will explore bundle size reduction optimisations based on TypeScript static analysis, making TypeScript the first-class citizen of Rspack. Implement optimizations such as private field removal and class properties mangling to further reduce Rspack's output size.
Portable persistent cache
Rspack will develop a portable persistent cache based on webpack's persistent cache. This will make Rspack's build cache not only persistent, but also portable to different environments and machines. This will help large projects and teams make better use of the cache and lay the foundation for distributed builds.
Stabilized lazy compilation
Rspack currently implements experimental lazy compilation and can delay the compilation of unused page entries and dynamic modules. The current version is aligned with webpack's implementation, and the functionality is not yet fully mature.
We predict that compilation tools written in JavaScript will continue to be widely used, including Babel (as well as React Compiler), PostCSS, Less, Vue Compiler, etc. Therefore, Rspack will need to provide more mature lazy compilation technology to avoid startup performance degradation caused by JavaScript-based compilation tools, allowing large web applications to start up faster.
Built-in CSS supports
Rspack has made several improvements to webpack's experiments.css to make it stable for use in most scenarios. For compatibility with the default behaviour of webpack v5, the default value of experiments.css in Rspack v1 remains false.
Rspack 2.0 will enable experiments.css by default, further improving its usability, and remove the experiments flag. This means that CSS will become a first-class citizen in Rspack by default. Additionally, HTML may also become a first-class citizen in Rspack in the future.
Rust plugins
Rspack currently provides good support for webpack's JavaScript plugins, while also having an internal Rust plugin system that provides similar hooks. The performance of Rust plugins is significantly better than JavaScript plugins. In the future, Rspack will provide mechanisms for custom Rust plugins. Possible solutions include directly invoking Rspack Rust API for source code integration, Wasm plugins (similar to SWC's Wasm plugins), and dynamic linked libraries.
Full Rust and Rust API
Currently, the Rspack core still contains some TypeScript modules and dependencies (such as watchpack and browserslist). After the release of Rspack 1.0, we will continue to Rustify Rspack by rewriting more TypeScript modules in Rust to improve performance.
This also helps align the consistency between Rspack's Rust API and JavaScript API. Rspack will build on this foundation to provide users with a stable and rich Rust API.
Fine-grained code splitting
Currently, the smallest unit for code splitting in Rspack is the module. In the future, Rspack will explore finer-grained code splitting, splitting modules into statements and using top-level statements as the smallest unit for code splitting. This will help to further reduce the bundle size. Additionally, Rspack can provide this metadata to minimizers, allowing them to perform more effective dead code elimination.
Closing Remarks
The above summarizes the main points discussed at this brainstorm meeting. We believe that each topic is worthy of further discussion and design. If you are interested in any of these topics, feel free to engage with us via GitHub Discussions, Discord or other forms of communication.
Chinese version
Rspack team 于 2024 年 7 月在线下举行了一次 brainstorm meeting，我们讨论了当下一些关键问题的解决方案，畅想了 Rspack 以及生态未来的发展方向。
这篇文档总结了会议中讨论的一些关键问题，以便于 Rspack 的贡献者和使用者了解 Rspack 未来的 Roadmap。
Rspack 技术栈
我们已经基于 Rspack 开发了一系列高性能工具，包括 Rsbuild、Rspress、Rsdoctor、Rslib（即将开源） 和 Rspeedy（即将开源）。
在本次会议上，我们通过投票决定，使用 "Rstack" 来统称基于 Rspack 的这一系列工具（过去我们曾称它们为 Rsfamily），"Rstack" 是 "Rs" 和 "Stack" 的组合，代表以 Rspack 为核心的一整套技术栈。
Rspack 2.0 和 webpack 的关系
Rspack 1.0 是对标 webpack v5 设计的，这帮助了大量使用 webpack 的项目平滑地迁移到 Rspack。但这是一个双刃剑，对 webpack 的兼容限制了 Rspack 的设计，使 Rspack 无法在 API、架构、产物格式、构建性能等方面达到最优解。
在 Rspack 未来的大版本中，将逐步引入一些对 webpack v5 的 breaking change（Rspack 2.0 将是我们心中的 webpack v6 应有的样子）。这有助于 Rspack 改进 API 设计，进一步提升构建性能，并实现更多强大的新特性。
此外，我们将进一步完善 Rsbuild，通过 Rsbuild 来提供更现代的 API 和配置，降低用户和插件开发者的上手成本。
Rspack 2.0 计划于 Rspack 1.0 发布之后的 12～18 个月左右推出。
基于 TypeScript 的代码优化
Rspack 将探索基于 TypeScript 静态分析的产物体积优化方案，将 TypeScript 作为 Rspack 的一等公民，实现诸如 private field 移除、class properties mangle 等优化技术，从而进一步减小 Rspack 构建产物的体积。
可移植的持久化缓存
Rspack 将在 webpack persistent cache 的基础上，进一步实现 portable persistent cache，这意味着 Rspack 的构建缓存不仅是持久化的，同时也可以被移植到任何不同的环境和机器，这将帮助大型项目和团队更好地利用缓存，并为分布式构建奠定基础。
稳定的 lazy compilation
当前 Rspack 实现了实验性的 lazy compilation，能够延迟编译未使用的 entry 和 dynamic modules。目前的版本是对标 webpack 实现的，功能仍然不够成熟。
我们预测由 JavaScript 编写的编译工具依然会被广泛使用，包括 Babel（以及 React Compiler）、PostCSS、Less、Vue Compiler 等。因此，Rspack 需要提供更成熟的 lazy compilation 技术，以避免基于 JavaScript 的编译工具导致的 dev startup 性能劣化，使大型 web 应用可以更快地启动。
内置 CSS 支持
Rspack 已经对 webpack 的 experiments.css 进行了许多改进，使它可以稳定用于绝大部分场景。为了保持对 webpack v5 默认行为的兼容，Rspack v1 的 experiments.css 默认值依旧为 false。
Rspack 2.0 将默认开启 experiments.css，进一步改进其可用性，并移除 experiments 标记，这意味着 CSS 将成为 Rspack 默认的一等公民。此外，未来 HTML 也可能成为 Rspack 的一等公民。
Rust 插件
Rspack 目前对 webpack 的 JavaScript 插件提供了良好的支持，同时 Rspack 内部也有一套提供对等 hooks 的 Rust 插件系统，并且 Rust 插件的性能显著优于 JavaScript 插件。Rspack 将在未来提供自定义 Rust 插件的机制，潜在的方案包括：直接调用 Rspack Rust API 进行源码集成、Wasm 插件（类似 SWC 的 Wasm 插件）以及动态链接库。
Rust 化和 Rust API
目前 Rspack core 中依然包含了一些 TypeScript 模块和依赖（比如 watchpack 和 browserslsit）。在 Rspack 1.0 发布后，我们将进一步将 Rspack Rust 化，将更多 TypeScript 模块重写为 Rust 以提升性能。
这也有助于对齐 Rspack Rust API 和 JavaScript API 的一致性，Rspack 将以此为基础，为用户提供稳定、丰富的 Rust API。
细粒度代码拆分
目前 Rspack 进行代码拆分的最小单元是 module。未来 Rspack 将探索更细粒度的代码拆分，将 module 分成 statement 语句，并将 top level 的 statement 作为 coding splitting 的最小单位，这将有助于进一步减少产物体积。此外，Rspack 也可以将这些元信息提供给 minimizers，使 minimizers 可以更好地进行死代码消除。
结语
以上是本次 brainstorm meeting 中讨论的主要内容，我们认为其中每个话题都值得更深入的讨论和设计，如果你对其中的话题感兴趣，欢迎通过 GitHub Discussions、Discord 或其他方式与我们讨论。
Beta Was this translation helpful? Give feedback.
All reactions