Rsbuild v1.0 Release Plan

[chenjiahan]

Introduction

We plan to release Rsbuild v1.0 before July 2024 (based in Rspack v1.0). The current topic lists the architectural changes and key features that we plan to implement before v1.0.

Architecture

Library Build Mode

In 2024, we will implement a new tool named Rslib based on Rsbuild, which will provide the library build mode.

Since there are significant differences in the process and requirements between library building and application building, it can be expected that there will be certain gaps in Rsbuild in terms of configuratios, output formats, etc.

Before the Rsbuild 1.0 version, we need to clarify some key design for Rslib, including how to implement multiple-build configs, how to support bundleless, how to support esm / cjs / dts outputs.

Native CSS Extract

Currently, Rsbuild uses different CSS implementations in Rspack mode and Webpack mode. Rspack mode uses the experimental CSS, while Webpack mode uses the mini-css-extract-plugin. Which means we need to maintain two separate sets of code.

Compared to mini-css-extract-plugin + css-loader, the capabilities of experimental CSS are weaker, such as CSS modules support, which has led to some issues. We plan to migrate to the native mini-css-extract-plugin of Rspack, polish this feature to stability as soon as possible (including the stability of its dependent new tree shaking), and unify the of CSS implementation.

See: web-infra-dev/rspack#3210

Stablize API

After the iterations of Rsbuild v0.1 ~ v0.4, most configurations and JavaScript API have become stable, but there are still some APIs that are not completely stable.

Before v1.0, the following APIs need to be stabilized:

• rsbuild.getServerAPIs(): Server APIs for upper-level frameworks, which need to be stabilized ASAP, and provide documentation for users.
• Remove the html.tagsByEntires config: html.tagsByEntires can be transformed into a function based on html.tags since all other html.xxxByEntries configs have been removed.
• Remove output.enableCssModuleTSDeclaration config, and implement it as an external plugin. see #482.
• Consider whether to redesign output.disableMinimize since all other output.disableXXX configs have been removed.

ESM Package

Many popular libraries in the community have now converted to pure ESM packages. Rsbuild has already completed the ESM supports for all plugins and now provides both ESM and CJS outputs.

@rsbuild/core and @rsbuild/shared in Rsbuild do not yet provide ESM outputs yet. The challenge is that these two packages have a large number of subpath exports and some loaders that need to be bundled separately. Improper build configuration can result in duplicate bundling of some modules.

Before the release of v1.0, we need to finish the ESM support for all packages. And we plan to maintain the CJS outputs for 1-2 years until most of the upper-level frameworks no longer need CJS outputs.

See #99.

Key Features

Plugin Ecosystem

Currently, the plugin ecosystem of Rsbuild is still in its early stages, with most plugins being officially implemented, and a few third-party plugins in the community (see awesome-rspack). We need to sort out the commonly used build plugins in the community, and evaluate whether these plugins need to be implemented by the Rsbuild team. We also hope to help community developers to develop more Rsbuild plugins.

When implementing these plugins, we want to improve Rsbuild's plugin hooks and APIs:

• Provide more plugin hooks, such as HTML-related hooks.
• Expose some important Rspack plugin hooks as Rsbuild plugin hooks.

PWA Support

PWA / service worker is an important feature, which can to be used in static sites like Rspress. In Rsbuild, we need to provide an out-of-the-box PWA solution and consider how to integrate it into Rspress.

We also need to improve Rspack's support for workbox-webpack-plugin, see web-infra-dev/rspack#4692

Web Worker Support

Rspack provides default support for web workers, but in practice, there are still many issues related to web workers.

We may not be able to solve all the issues in the short term, but we can provide a best practice for web workers, so that users can use web workers according to the recommended way.

See: webpack/webpack.js.org#6716

Lightning CSS Support

Lightning CSS is a popular CSS transformer based on Rust. It can solve the performance overhead caused by PostCSS + autoprefixer in the current Rsbuild, and it can also replace SWC CSS for CSS compression.

At present, we cannot determine whether Rspack will integrate Lightning CSS in the future, or replace SWC CSS. However, Rsbuild can first support the integration of Lightning CSS as a plugin, to verify the benefits of Lightning CSS.

https://lightningcss.dev/

Error Overlay

In terms of development experience, Rsbuild currently does not provide built-in error overlay, and there is no suitable error overlay plugin in the webpack ecosystem. Therefore, we plan to implement error overlay ourselves to improve development experience.

See: #552

Rebuild Performance

Currently, Rspack does not supports lazy compilation and persistent cache, which may cause slow rebuild in some Rsbuild projects. And it will take some time to add these capabilities to Rspack.

In the meantime, we can apply some lightweight cache solutions in Rsbuild to improve rebuild performance. For example, after Rsbuild integrated babel-loader cache, we found significant performance improvements (3s -> 2s in Vant website, #1621).

Besides babel, the compilation of less / sass / vue files can also benefit from the cache. The webpack community usually uses cache-loader to achieve this. Since rspack does not support cache-loader, we can implement a rspack-cache-loader for Rsbuild.

[DominusKelvin]

This is really good.

I'm using Rsbuild over at Sails.js with Sails Shipwright and these two things are interesting to me:

• Manifest file support like in Vite
• If possible at the plugin level the ability to inject script and css tags into any file like .ejs or .html

I'm also really excited at the support of PWA and I can't wait to play around with these new features in Rsbuild 1.0

[chenjiahan]

Thanks ❤️

• Manifest support should be launched before v1.0, issue: [Feature]: Support output.manifest config #989
• How about configuring output.inlineScripts in the plugin level (using api.modifyRsbuildConfig())

[DominusKelvin]

Thanks ❤️

• Manifest support should be launched before v1.0, issue: [Feature]: Support output.manifest config #989

• How about configuring output.inlineScripts in the plugin level (using api.modifyRsbuildConfig())

Nice looking forward to manifest file support

Also I don't think inline script is what I'm looking for. My use case is for both production and development I want to be able to inject the scripts and css in body and head respectively. Doing so will let me in production inject the css and script with their hashes

[DominusKelvin]

Hey @chenjiahan what do you think about that? For reference here is this Vite directive provided in Laravel

https://laravel.com/docs/10.x/vite#loading-your-scripts-and-styles

[fernandojbf]

I'm really excited to see Rslib in action!
Currently, i'm using swc with tsc in our library monorepo, and tsc is causing some serious slowdowns—it's a real bottleneck in our system. If we could find a solution with a buildless tool that supports declaration exports, that would be fantastic! 🎉

[chenjiahan]

Yes, tsc is the biggest bottleneck at the moment, unfortunately, Rslib also has to rely on tsc to export types. Stc was once the most exciting alternative, but it has stopped iterating.

[fernandojbf]

Yap :(.
We were having expectations for Stc too...

[JoseVSeb]

what's the status of Rslib?

[chenjiahan]

It's still in early stage and we will open source it soon, maybe next week

[chenjiahan]

The Rslib repository is now public: https://github.com/web-infra-dev/rslib

[ruibaby]

The Rslib repository is now public: web-infra-dev/rslib

Awesome!