☂️ Iteration plan for Q4 (Oct-Dec)

[hardfist]

See #3679 for Q3 iteration plan.

This issue serves as an Epic to provide transparency for our community and collaborators, internal and external, informed about our current goals and timelines.

We will be actively working on the tasks listed below, which have been aligned with our goals for Q4 (Oct - Dec 2023).

If you see something that is not on this list but is strongly needed. Please write a detailed requirement on this issue if you feel the need for feature prioritization. Also, remember this is not a complete list, so please search for relevant issues beforehand.

For broader collaboration, you can also find us on Discord if you need a quick chat.

---

Module federation support

Module federation is one of the most requested features by the community (#1930). In this quarter, we will experimentally support Module Federation in Rspack.

Rsbuild: out of box react and vue solution

In the early stages, we provided an out-of-the-box experience for React in Rspack. However, this led to compatibility issues with webpack. During the optimization and compatibility process with webpack, we realized that providing out-of-the-box support for frameworks like React and Vue in Rspack CLI is not suitable. Additionally, the community lacked a lightweight Client-Side Rendering (CSR) solution. Therefore, in Rsbuild, we will provide:

• Out-of-the-box solutions for frameworks like React and Vue, eliminating the need for configuring Rspack from scratch.
• Lower migration costs, reducing the migration effort for webpack projects, CRA projects, and Vue CLI projects.
• Built-in build analysis capabilities, offering powerful analysis for artifacts, loaders, plugins, and more.
• Good compatibility support, providing out-of-the-box support for modern and legacy browsers.
• More built-in engineering capabilities, including type checking, monorepo support, barrel file optimization, and more.
• Flexible extension capabilities, allowing for easy extension of features such as Module Federation.

mini-css-extract-plugin support

Rspack supports extract CSS through the experiments.css feature. However, we encountered several limitations with experiments.css in practical applications (webpack/webpack#14893). Therefore, we plan to implement the mini-css-extract-plugin in Rspack to reduce the migration costs for businesses.

Better tree shaking support

In earlier versions, we implemented tree shaking logic in Rspack based on the approach from esbuild. However, we found that the current tree shaking optimization in Rspack is weaker than webpack's tree shaking optimization in real-world scenarios (#3625, evanw/esbuild#2049). In Q3 and Q4, we have referred to webpack to re-implement new tree shaking capabilities in order to address the issue of increased bundle size when migrating from webpack to Rspack in certain edge cases.

Better Unplugin Support

Currently, Rspack's support for unplugin is not comprehensive, which limits many users who rely on unplugin from migrating to Rspack (#4198, #3408). This quarter, we will optimize support for unplugin to accommodate more unplugin plugins.

Stable Node API and CLI

We plan to release alpha version 1.0 in 2024. In this quarter, we will focus on ensuring the stability of Rspack CLI and Node API, making sure that the public API is sufficiently stable.

Better Diagnostics and Error Report

Diagnostics and error reports are crucial in daily development.
In current error report, we don't have a category to distinguish the difference between each error and the error frame showing also does not have the right code location in somecases:

In this roadmap, we will try to tackle this issue in these aspects:

• Provide diagnostics and easy to read error overlay
• Align most of the diagnostic information with webpack

Dev Guide Documentation

Currently, Rspack still presents certain barriers for external contributors. This quarter, we will optimize the developer guide, improve the architecture and internal implementation documentation of Rspack and webpack, and provide more contribution guidelines to lower the barriers for developers to contribute.

Improve Performance

Currently, Rspack may still have some performance bottlenecks in some large applications, and we will continue to optimize these performance bottlenecks (such as sourcemap), and begin to implement persistent cache , because of the complexity of persistent cache, its implementation may take more than one quarter.

[Thiry1]

Are there any plans to move forward with implementing a persistent caching?
In our huge product, webpack is faster when cache is available.
This is the only reason we are not using rspack in our huge product at this time.

[WbaN314]

Are there any plans to move forward with implementing a persistent caching? In our huge product, webpack is faster when cache is available. This is the only reason we are not using rspack in our huge product at this time.

Similar situation here. No real improvement in dev experience, as the webpack with persistent cache build time is about the same as the rspack without persistent cache build time.

[hardfist]

Are there any plans to move forward with implementing a persistent caching? In our huge product, webpack is faster when cache is available. This is the only reason we are not using rspack in our huge product at this time.

we're working on persistent caching this quarter but we can't promise we will support persistent caching this quarter. and I'm curious about your build time in rspack and webpack with persistent cache

[Thiry1]

Thanks for working on it!Can't wait for the release 😄

I'm curious about your build time in rspack and webpack with persistent cache

I measured in mode: "development".(As an indication of the size of the codebase, the size of the output js file is about 6.6M)
rspack: 10469 ms
webpack(cache unavailable): 42885 ms
webpack(cache available and no file changes): 718 ms
webpack(cache available and 1 file changes): 1330 ms

As you can see, webpack is faster when cache is available.

[1yasa]

I've been building production applications with rspack since the beginning of this year. Rspack's build process is fast, but what's been frustrating is that as the number of project components has increased, the HMR (Hot Module Replacement) and dev server startup speed has been getting slower. This wasn't an issue when I was using TurboPack with Next.js. I suspect the key might be lazy compilation.

Rspack has always been focused on improving development speed. When can we expect to experience lazy compilation and pre-bundled dependencies in rspack?

[hardfist]

Rspack has always been focused on improving development speed. When can we expect to experience lazy compilation and pre-bundled dependencies in rspack?

thank you for trying rspack, startup speed is indeed highly coupled with lazy compilation and we will plan to support lazy compilation in 2024-Q1 because we need to make sure the build artifacts is stable enough first so people can use it on production. HMR is not highly coupled with lazy compilation so if you met some HMR performance problem you can file a issue so we can find the cause of it.

[hardfist]

Thanks for working on it!Can't wait for the release 😄

I'm curious about your build time in rspack and webpack with persistent cache

I measured in mode: "development".(As an indication of the size of the codebase, the size of the output js file is about 6.6M) rspack: 10469 ms webpack(cache unavailable): 42885 ms webpack(cache available and no file changes): 718 ms webpack(cache available and 1 file changes): 1330 ms

As you can see, webpack is faster when cache is available.

thank you for your data, it's a good reference for use on the priority of persistent cache

[1yasa]

It seems that in terms of HMR granularity, rspack isn't as fine-grained as TurboPack. This results in occasional HMR times exceeding 1 second for complex applications, which can be quite detrimental.

[hardfist]

It seems that in terms of HMR granularity, rspack isn't as fine-grained as TurboPack. This results in occasional HMR times exceeding 1 second for complex applications, which can be quite detrimental.

@whatreal can you help file a separate issue and provide profile using https://www.rspack.dev/guide/profile.html so we can dig into

[1yasa]

It seems that in terms of HMR granularity, rspack isn't as fine-grained as TurboPack. This results in occasional HMR times exceeding 1 second for complex applications, which can be quite detrimental.

@whatreal can you help file a separate issue and provide profile using https://www.rspack.dev/guide/profile.html so we can dig into

Sorry, for confidentiality reasons, I can't provide reproduction code. I'm just offering my speculation here, that the HMR slowness might be due to insufficient granularity in the captured code.

[hardfist]

Sorry, for confidentiality reasons, I can't provide reproduction code. I'm just offering my speculation here, that the HMR slowness might be due to insufficient granularity in the captured code.

we dont need the code here，just need the profile file which generated according to https://www.rspack.dev/guide/profile.html

[1yasa]

Sorry, for confidentiality reasons, I can't provide reproduction code. I'm just offering my speculation here, that the HMR slowness might be due to insufficient granularity in the captured code.

we dont need the code here，just need the profile file which generated according to https://www.rspack.dev/guide/profile.html

I see, you're referring to granularity issues in the HMR phase. You are satisfied with the build phase speed.

[kklem0]

Thanks for working on it!Can't wait for the release 😄

I'm curious about your build time in rspack and webpack with persistent cache

I measured in mode: "development".(As an indication of the size of the codebase, the size of the output js file is about 6.6M) rspack: 10469 ms webpack(cache unavailable): 42885 ms webpack(cache available and no file changes): 718 ms webpack(cache available and 1 file changes): 1330 ms

As you can see, webpack is faster when cache is available.

dev environment's speed is important for us as well, as speed is why we use rspack, looking forward for implementing these.

[hardfist]

dev environment's speed is important for us as well, as speed is why we use rspack, looking forward for implementing these.

do you meet dev speed problem now? can you share the profile data with us?

[doerme]

When will module federation be supported?

[ClearLuvMoki]

我将我司的桌面端（electron）的项目迁移到rspack，说实话真的很快（对比webpack，大约快了一半多），目前就是对于两点感觉支持的有问题，第一个是styled-components支持不好，第二个是对import lazy感觉不行，有时候经常报上游rust的tokio的异步错误，然后卡死

[hardfist]

When will module federation be supported?

@doerme #4642 under construction, a poc end of this month

[hardfist]

真的很快（对比webpack，大约快了一半多），目前就是对于两点感觉支持的有问题，第一个是styled-components支持不好，第二个是对import lazy感觉不行，有时候经常

we support styled-components recently if you met problems please file issue to us

[mavridiSS]

When will mini-css-extract-plugin be supported?

[Chevindu]

Excited for the Rsbuild! I think I can finally convince my architect to abandon the CRA wreck.

[jainChetan81]

Thanks for working on it!Can't wait for the release 😄

I'm curious about your build time in rspack and webpack with persistent cache

I measured in mode: "development".(As an indication of the size of the codebase, the size of the output js file is about 6.6M) rspack: 10469 ms webpack(cache unavailable): 42885 ms webpack(cache available and no file changes): 718 ms webpack(cache available and 1 file changes): 1330 ms

As you can see, webpack is faster when cache is available.

@Thiry1 This looks really good, can you share how are you using persistent cache for webpack build..?
Because we are using in-memory cache for webpack build which isn't really fast and filesystem breaks very often...

[Thiry1]

@jainChetan81 I use the following configurations.
I guess you need to check the buildDependencies setting is correct.
BTW, this is off-topic and should be discussed in the webpack repository.

{
  type: "filesystem",
  buildDependencies: {
    config: [__filename],
  },
}