Announcing Rspack 1.2

January 21, 2025

Rspack 1.2

Posted by @jerrykingxyz, @chenjiahan, @JSerFeng, @ahabhgk


Rspack v1.2 has been released!

Notable changes:

New features

Persistent cache

Rspack v1.2 introduced an experimental cache configuration that supports persistent caching, which can significantly improve hot startup speed.

rspack.config.js
module.exports = {
  cache: true,
  experiments: {
    cache: {
      type: 'persistent',
    },
  },
};

When a build hits the cache, it can bring up to 250% performance improvement in real projects.

Project type Number of modules Normal dev Cold dev Hot dev
Initial project 26 146 ms 149 ms (+2%) 134 ms (-8%)
Project with 10000 modules 10040 2.43 s 2.43 s (+0%) 1.16 s (-52%)
Project with Less files 1898 3.47 s 3.55 s (+2%) 0.92 s (-73%)
Large real project 45968 93.3 s 91.9 s (-1%) 26 s (-72%)

Note that persistent cache is still in an experimental stage and currently only supports the make stage of the build process (including module resolution, transformation, etc.). We will continue to optimize it in the future to further improve cache performance and coverage.

If you encounter any issues while using persistent cache, please feel free to report them via GitHub Issues.

See experiments.cache for more details.

Yarn PnP

Rspack has added support for Yarn PnP, which is enabled by default based on process.versions.pnp (that is, when the application is running in a Yarn pnp environment), and can also be forced to enable by configuring resolve.pnp to true.

rspack.config.js
module.exports = {
  resolve: {
    pnp: true,
  },
};

Special thanks to @arcanis, the lead maintainer for Yarn, for implementing PnP resolution in the Rspack resolver.

See resolve.pnp for more details.

Performance improvements

Faster code splitting

In previous versions of Rspack, the code splitting would take up a lot of time under HMR. In Rspack v1.2, we implemented a new code splitting algorithm that supports multithreading and more efficient incremental rebuilds. If your code base contains a lot of dynamic imports, and code splitting will take a lot of time. Enabling this new feature can significantly improve the performance of code splitting.

rspack.config.js
module.exports = {
  experiments: {
    parallelCodeSplitting: true,
  },
};

See experiments.parallelCodeSplitting for more details.

Watch scope change

Rspack v1.2 no longer watching the node_modules directory by default. This can greatly reduce the number of files to watch and improve performance.

According to our benchmark repo, this change will:

  • Reduce memory usage by 120MB
  • Increase dev startup speed by 40%
  • Increase HMR speed by 20~30%

This change will not affect symlinked resources in monorepo, as symlinked resources are resolved to their real path by default.

If you prefer to keep the previous behavior, you can set:

rspack.config.js
module.exports = {
  watchOptions: {
    ignored: [],
  },
};

See watchOptions.ignored for more details.

Reduced memory usage

We have optimized the data structure used to store strings during the rspack-sources computation process. Throughout the computation, all string data points to the string heap memory of the root node, effectively avoiding the generation of new string allocations during the computation.

See perf: reduce memory consumption of CachedSource for more details.

Smaller minification size

Rspack v1.2 set default SWC minimizer passes to 2 to reduce bundle size by 1%-7%.

new rspack.SwcJsMinimizerRspackPlugin({
  minimizerOptions: {
    compress: {
      // Defaults to 1 in previous versions
      passes: 2,
    },
  },
});

passes is the the maximum number of times to run compress. In some cases, more than one pass leads to further compressed code. Given Rspack's inherent speed, we've determined that using 2 passes by default strikes an optimal balance between build performance and bundle size.

See feat: set default SWC minimizer passes to 2 to reduce bundle size for more details.

Faster side effects optimization

The implementation of side effects optimization has been refactored to be simpler and more parallelism-friendly. It can take full advantage of parallelism to improve performance. In tested projects, there is typically a 2x-3x performance improvement at this stage.

See perf: parallelize side effects optimization for more details.

Ecosystem

Angular support

Nx team core member Colum Ferry has brought complete Angular support to the Rspack ecosystem.

With the newly released @ng-rsbuild/plugin-angular and @ng-rspack/build packages, developers can now use Rspack or Rsbuild to build Angular applications, with faster build performance and module federation support.

Please visit ng-rspack-build for more information.

Rsbuild v1.2

Rsbuild v1.2 has been released alongside Rspack v1.2, bringing several new features:

For more details, see Rsbuild v1.2.0.

Upgrade guide

Upgrade SWC plugins

In Rspack v1.2, the Rust crate swc_core has been upgraded to 10.1.0. Users of the SWC Wasm plugin need to ensure version consistency with swc_core being used, otherwise, it may lead to unforeseen issues.

For more details, see FAQ - SWC plugin version unmatched.

Disable WarnCaseSensitiveModulesPlugin by default

The WarnCaseSensitiveModulesPlugin is used to check the paths of modules and issue warnings for modules that conflict when their paths are all in lowercase. Rspack used to enable it by default, but since it is only a "linter" plugin and it has additional performance overhead especially in development mode. So now it is disabled by default.

If you prefer to keep the previous behavior, you can set:

rspack.config.js
module.exports = {
  plugins: [new rspack.WarnCaseSensitiveModulesPlugin()],
};