Approximately a quarter-year post the unveiling of Rspack 0.1, we've been met with robust community engagement and constructive critique. With the advent of Rspack 0.2, we've augmented our offering with key advancements, including but not limited to, realContentHash for enhanced cache reliability, DataURI for inline asset handling, and native support for the ESM file format. Our technical strides also include strengthened synergies with webpack's API, culminating in full compatibility tests with vue-loader for both Vue3 (version 17) and Vue2 (version 15). We extend an open invitation for you to explore these newly-incorporated features in Rspack 0.2 and are keen to assimilate your expert feedback.

Main feature updates

Loader

Version 0.2 has completed compatibility with most of the loader APIs, including: inline match resource, pitching loader, and inline loader. More APIs have further improved compatibility with webpack loaders, details of which can be found in our webpack compatibility updates Loader API.

Plugin Hooks

New hooks for plugins have been added.

Compiler hooks:

1. beforeCompile
2. afterCompile

Compilation hooks:

1. optimizeModules
2. optimizeChunkModule
3. finishModules
4. chunkAsset

NormalModuleFactory hooks:

1. beforeResolve
2. afterResolve
3. ResolveForScheme

ContextModuleFactory hooks:

1. beforeResolve

realContentHash

We have implemented optimization.realContentHash, which calculates the Hash based on the final product's file content. This makes the generated Hash more stable and is better utilized for caching. In version 0.2, this feature will be enabled by default for production environment builds.

ESM/System format

In the new version, System/ESM products can be generated, and the configuration for outputting ESM products is as follows:

//rspack.config.js
module.exports = {
  // …
  experiments: {
    outputModule: true,
  },
  output: {
    chunkFormat: 'module',
    chunkLoading: 'import',
    library: {
      type: 'module',
    },
  },
};

New SplitChunksPlugin implementation

We have restructured the existing implementation of SplitChunksPlugin in Rspack, making the behavior of SplitChunksPlugin more predictable and reducing the cost of troubleshooting related issues.

After the restructuring, we are confident to implement more features on SplitChunksPlugin. We are pleased to announce that in version 0.2, SplitChunksPlugin supports the following configuration options:

• splitChunks.maxSize
• splitChunks.maxAsyncSize
• splitChunks.maxInitialSize
• splitChunks.maxAsyncRequests
• splitChunks.maxInitialRequests

In version 0.2, we will use the new SplitChunksPlugin by default. If you encounter problems, please provide feedback promptly, and we will fix them as soon as possible. You can switch back to the deprecated implementation by using the experiments.newSplitChunks: false option, but we strongly recommend using the new version. In version 0.3, we will remove the deprecated implementation.

DataURI support

We have implemented support for DataURI. Now you can write the following code to implement virtual modules:

import x from 'data:text/javascript,export default 42';

In addition, we have supported mimetype and scheme as two types of module rule conditions. For example, you can make resources with scheme as 'data' no longer treated as inline processing, but as separate resource files through the following method:

//rspack.config.js
module.exports = {
  module: {
    rules: [
      {
        scheme: 'data',
        type: 'asset/resource',
      },
    ],
  },
};

Breaking Changes

• Alignment of Filename Generation Logic

In version 0.1.12, we further aligned the file name generation logic with webpack, and refactored the implementation of file name generation. However, the [ext] in output.filename, output.chunkFilename, output.cssFilename, and output.cssChunkFilename will no longer be replaced. This behavior is now consistent with webpack but is a breaking change for versions of Rspack prior to 0.1.12. If you used [ext] in the above 4 filename configurations, you need to change it to the corresponding .js or .css, for example:

  module.exports = {
    output: {
  -    filename: "[name][ext]",
  +    filename: "[name].js",

  -    chunkFilename: "async/[name][ext]",
  +    chunkFilename: "async/[name].js",

  -    cssFilename: "[name][ext]",
  +    cssFilename: "[name].css",

  -    cssChunkFilename: "async/[name][ext]",
  +    cssChunkFilename: "async/[name].css",
    }
  }

Details: https://github.com/web-infra-dev/rspack/issues/3270

• Enabled realContentHash by default in production

Details: https://github.com/web-infra-dev/rspack/pull/3338

• Modified the Extensions of Resolve

Details: https://github.com/web-infra-dev/rspack/pull/3242

• Modified the Export Method of @rspack/dev-middleware and @rspack/html-plugin, and Removed getRspackMemoryAssets Exported by @rspack/dev-middleware

Details: https://github.com/web-infra-dev/rspack/pull/3358

Webpack Compatibility Updates

As we support more webpack APIs, we are also compatible with more community plugins and loaders. We have adapted some plugins and loaders that have a high demand in the community.

fork-ts-checker-webpack-plugin

Type checking in TypeScript for Rspack is highly demanded. Rspack has fully adapted fork-ts-checker-webpack-plugin. You can use this plugin to perform TypeScript type checking during compilation. However, as TypeScript's type checking is usually very time-consuming, this makes the time required for type checking on larger projects may far exceed the build time of Rspack itself. In dev mode, this plugin will not block the build, but in build mode, this plugin will block the build. Please choose whether to enable this plugin based on your actual needs.

license-webpack-plugin

A widely reported community demand is support for extracting licenses from code. Now, Rspack can achieve the requirement of extracting licenses from the code through license-webpack-plugin.

style-loader & css-loader

Although Rspack supports and enables the experiments.css feature of webpack by default, there are still many communities that strongly depend on style-loader & css-loader. We have completed support for style-loader and css-loader in 0.2.0, which also allows us to better adapt to frameworks such as Svelte and Vue.

node-loader

When using Rspack to package Node applications like Nestjs, a common requirement is to package libraries containing addons. These libraries' native dependencies cannot be directly packaged into js, so they need special treatment. Rspack has adapted node-loader, so you can now use Rspack to build node applications.

Rspack has additional adaptation of webpack's plugins. We have tracked the adapted plugins and loaders in loader-compat and plugin-compat. If you find that a community plugin or loader you are using is also compatible, welcome to submit it to us so we can list it in our compatibility matrix.

Framework Ecosystem Updates

Modern.js Framework

Thanks to the close collaboration and parallel iteration of the Modern.js framework and Rspack, Modern.js Rspack mode has covered 85% of the framework's capabilities, supporting SSR, BFF, micro front-end scenarios, and aligning with TypeScript type checking, code compatibility detection and other features.

At ByteDance, more than 80 projects are using the Modern.js Rspack mode. Some of the projects have been deployed into production and have seen a 10x improvement in build performance.

Modern.js Doc

In addition to the Modern.js framework, the document site solution under the Modern.js system - Modern.js Doc - has also switched the bundler from webpack to Rspack, and rewritten the MDX compilation process based on Rust.

Compared to previous versions using webpack, the current version's build speed can be reduced to seconds. Using the Modern.js official website documentation as an example, the project's startup and build time has been reduced from 30 seconds to less than 2 seconds. In the future, we plan to rename Modern.js Doc to Rspress as the official documentation site solution for Rspack and maintain it through a separate repository.

Welcome to visit the Modern.js code repository and experience the above content.

Vue

Rspack 0.2 has achieved compatibility with vue-loader! For Vue3 projects, you can use Rspack's native CSS and TS processors to improve the compilation speed of Vue projects. All you need to do is upgrade vue-loader to version 17.2.2 or above and set experimentalInlineMatchResource: true. For more information on Vue3/Vue2 support, please refer to guide-vue.

Svelte

Thanks to Rspack's excellent support for the Loader API and the excellent design of svelte-loader, Rspack has fully adapted svelte-loader. Therefore, you can directly use svelte-loader in Rspack for svelte application development. You can refer to example-svelte to complete the svelte-loader related configuration.

Storybook

With the help of the Storybook team, Rspack has completed support for the Storybook React version. You can follow the migrate Storybook method to migrate from the webpack version to the Rspack version. In actual projects, tests have shown that the Rspack version is 5-10 times faster than the Webpack version when the docgen feature is not turned on. When docgen is turned on, since Rspack still relies on babel to handle docgen, the performance is affected, but there is still a 2-3 times improvement.

Angular

With the help of the Valor team, Rspack has completed preliminary support for Angular. You can use Rspack to build Angular applications, but the support for dev and HMR has not yet been fully adapted. We will continue to follow up on Angular support in version 0.2.x.

NestJS

With the help of Rosa, Nx, and Valor, Rspack has completed the compilation support for NestJS. You can use Rspack to package NestJS applications, and in actual projects, tests have shown that Rspack has a 5-10 times build performance improvement compared to the webpack version.

Benchmark

Added a benchmark comparison with esbuild. Please refer to the following link for more details: https://github.com/web-infra-dev/performance-compare

Dev guide

The Rspack team cherishes the valuable contributions made by the open source community and wants to actively fosters collaboration. We are committed to maintaining an open approach, striving to engage and involve the community at every step.

This is why we are currently crafting a comprehensive development guide that equips contributors with all the essential materials required to facilitate the development of Rspack.

The current version of the guide contains all the necessary materials for building, testing, debugging, and profiling Rspack. Additionally, it includes contribution procedures, such as creating a minimal reproducible example.
In the future, the guide will offer an insightful overview of Rspack's architecture, enabling contributors to gain a profound understanding of the project's intricate inner workings.

Test infrastructures

In order to ship with confidence, we are currently:

• Building and testing a list of examples in the Rspack repository (currently 38 examples)
• Porting all webpack tests from the webpack repository
• Running all tests on Node 14, 16 and 18
• Maintaining a separate ecosystem-ci repository for integration tests

Nightly Release

In order to expedite iteration, Rspack is released daily with the "@nightly" tag to npm.

Acknowledgements

With the release of Rspack 0.2, we wholeheartedly thank all the contributors who have put effort into this version.

Special thanks to:

• @TheLarkInn and @alexander-akait, for answering and resolving many of Rspack team's questions about Webpack.
• @zackarychapple, @valorkin, @edusperoni, and @Coly101 for assisting the Rspack team with basic support for Angular and @zackarychapple for reviewing this release blog.
• @suxin2017, for supporting System.js format and optional-dependency functionality in Rspack, as well as contributing a lot in terms of Windows compatibility.
• @faga295, for supporting the decompression code comment feature and rspack preview feature in Rspack.
• @lippzhang, for making numerous contributions in aligning Rspack's behavior with Webpack.
• @HerringtonDarkholme, for allowing Rspack to use rspack.config.ts as a configuration file.
• @dhruvkelawala, for implementing the builtins.provide feature in Rspack.
• @magic-akari, for supporting the new URL("./foo", import.meta.url) syntax in Rspack.
• @tuchg, for supporting the packing of .wasm files in Rspack.

We also want to thank all the users of Rspack, for showing trust in such a young open-source project. Your valuable feedback plays a key role in our project improvements and optimizations. Your support and trust is our motivation to move forward.

Finally, let us collectively celebrate the release of Rspack 0.2 and look forward to future developments and more opportunities for collaboration. Thanks again to all friends who support and pay attention to Rspack!