#Announcing Rspack 2.1

June 26, 2026

Gengkun He

@ahabhgk

Yu Feng

@JSerFeng

Congcong Pan

@SyMind

Jiahan Chen

@chenjiahan

Zhiyong Chen

@CPunisher

Zhixin Jin

@intellild

Chenwei Dai

@Timeless0911

Lingyu Wang

@LingyuCoder

We are excited to announce the official release of Rspack 2.1!

Notable changes include:

• Performance improvements
  • Rust version of React Compiler
  • Build performance improvements
  • TypeScript 7 support
  • Faster circular dependency checks
• New features
  • Support for import.meta.glob
  • Improved built-in CSS support
  • Support for parsing createRequire
  • Rspack magic comments
  • Support for source phase imports
  • Automatic persistent cache cleanup
• Output optimization
  • pureFunctions stabilized
  • Branch-aware dependency pruning
  • Branch-aware ESM export presence checks
  • export const value binding optimization
• Ecosystem
  • TanStack RSC support
  • Rsbuild
  • Rslib
  • Rstest
  • Rslint
  • Rspress
  • Rsdoctor
  • rspack-merge

#Performance improvements

#Rust version of React Compiler

React Compiler is an official build-time optimization tool for React. It automatically adds appropriate memoization logic for components and Hooks during compilation, reducing the need to manually use useMemo, useCallback, and React.memo.

In the past, React Compiler was mainly integrated through babel-loader, which introduced additional Babel transform overhead and increased project build time. Now that React Compiler has been ported to Rust, SWC has also completed its integration. In Rspack 2.1, you can now enable React Compiler directly through the built-in SWC loader.

In our benchmark, the Rust version of React Compiler is around 7-13x faster than the Babel version:

Enable React Compiler through jsc.transform.reactCompiler in builtin:swc-loader:

export default {
  module: {
    rules: [
      {
        test: /\.(?:js|jsx|ts|tsx)$/,
        use: {
          loader: 'builtin:swc-loader',
          options: {
            detectSyntax: 'auto',
            jsc: {
              transform: {
                react: {
                  runtime: 'automatic',
                },
                reactCompiler: true,
              },
            },
          },
        },
      },
    ],
  },
};

For more configuration options, see the Rspack React Compiler guide.

#Build performance improvements

Build performance has always been one of Rspack's core priorities. In our benchmark, Rspack 2.1 improves production build performance by around 16% and HMR performance by around 5% compared with Rspack 2.0.

Data source: rspack-react-10k-benchmark

These improvements mainly come from three areas: a large number of micro-optimizations in the main build pipeline, optimized low-level data structures for the module graph and dependency relationships, and improvements to SWC parsing and transformation.

#TypeScript 7 support

TypeScript type checking is often one of the most time-consuming parts of the build pipeline. ts-checker-rspack-plugin now supports type checking with TypeScript 7 (TypeScript Go). In builds with type checking enabled, the overall time can be reduced by around 60%.

Install the TypeScript 7 RC version in your project to use it:

npm add typescript@rc -D

yarn add typescript@rc -D

pnpm add typescript@rc -D

bun add typescript@rc -D

deno add npm:typescript@rc -D

import { TsCheckerRspackPlugin } from 'ts-checker-rspack-plugin';

export default {
  plugins: [new TsCheckerRspackPlugin()],
};

#Faster circular dependency checks

Rspack 2.1 adds CircularCheckRspackPlugin, which replaces the deprecated CircularDependencyRspackPlugin.

import { rspack } from '@rspack/core';

export default {
  plugins: [new rspack.CircularCheckRspackPlugin()],
};

Compared with the old plugin, the new CircularCheckRspackPlugin brings two main improvements:

• Better performance: the old plugin's detection approach was closer to expanding circular paths from entries, which could cause repeated traversal in large module graphs. The new plugin uses a graph algorithm that is better suited for cycle detection. It can find circular components in a single analysis pass and generate readable circular paths for each component, reducing detection overhead in large projects.
• More reasonable API design: the old plugin's API design was less intuitive and inconsistent with the commonly used circular-dependency-plugin API in the webpack ecosystem. The new plugin returns to a more direct "detect and report circular dependencies" model, provides options that are more consistent with the webpack ecosystem, and is easier to understand and migrate to.

If you are using CircularDependencyRspackPlugin, we recommend migrating to CircularCheckRspackPlugin. If you only need to ignore certain warnings, you can use ignoreWarnings.

#New features

#Support for import.meta.glob

Rspack now supports import.meta.glob. You can collect modules by glob pattern and load them only when needed:

const pages = import.meta.glob('./pages/**/*.js');

for (const path in pages) {
  const mod = await pages[path]();
}

This feature is already available in Vite and Turbopack. With support in Rspack, developers can use a more consistent and familiar syntax across different ecosystem tools, reducing the cognitive cost of switching between them. It also lets framework and library authors who support multiple build tools reuse more similar implementation patterns.

See the import.meta.glob documentation for complete usage details.

#Improved built-in CSS support

Rspack 2.1 further improves built-in CSS support. The new css/global module type allows CSS Modules to work in a "global by default, opt into :local when needed" mode. Together with css/module and css/auto, it covers more scope organization patterns.

CSS Modules support also continues to improve, with more CSS Modules syntax and behavior now supported.

For related configuration, see the CSS options in module.generator and module.parser.

#Support for parsing createRequire

ESM modules do not have a built-in require, so Node.js provides module.createRequire(), which lets you create a require function inside ESM to load CommonJS modules. In previous versions, Rspack could not statically analyze the require created this way, so modules loaded by it could not be bundled correctly.

Rspack 2.1 adds the module.parser.javascript.createRequire option. When enabled, Rspack recognizes createRequire imported from Node.js module and converts the created require into a statically analyzable dependency context. Modules loaded through it can then be bundled just like modules loaded by ordinary require or import.

export default {
  module: {
    parser: {
      javascript: {
        createRequire: true,
      },
    },
  },
};

import { createRequire } from 'module';

const require = createRequire(import.meta.url);
const value = require('./value.cjs');

This option also supports:

• Multiple import forms: named imports, default imports, and namespace imports are supported, and imports from both module and node:module are recognized.
• Custom sources: in addition to true, you can customize the specifier and module source using a string in the "<specifier> from <module>" form, such as "createRequire from module".
• Statically analyzable arguments: the argument of createRequire() must be statically analyzable as a file URL or an absolute path, such as import.meta.url, new URL('./dir/file.js', import.meta.url), or an absolute file: URL.

This option is disabled by default. See module.parser.javascript.createRequire for details.

#Rspack magic comments

Rspack 2.1 adds support for the rspack prefix in magic comments. You can now use the rspack prefix to declare compilation hints:

import(/* rspackChunkName: "dashboard" */ './dashboard');

The existing webpack prefix remains compatible, so existing projects do not need to migrate.

See the magic comments documentation for details.

#Support for source phase imports

Rspack 2.1 supports the WebAssembly use case in the TC39 Source Phase Imports proposal. After enabling experiments.sourceImport, you can import .wasm modules through static import source or dynamic import.source().

Unlike normal WebAssembly imports, a source phase import does not instantiate the Wasm module during import. Instead, it returns a compiled WebAssembly.Module. This lets you control instantiation yourself, such as instantiating the same Wasm module multiple times with different imports, or reusing the same compiled result across multiple Web Workers to avoid the cost of repeated compilation.

export default {
  experiments: {
    sourceImport: true,
  },
};

import source wasmModule from './module.wasm';

const instance = await WebAssembly.instantiate(wasmModule, {
  // imports...
});

You can also use dynamic import:

const wasmModule = await import.source('./module.wasm');
const instance = await WebAssembly.instantiate(wasmModule);

Rspack also adds module.rules[].phase, which lets rules match modules by import phase. You can distinguish normal evaluation imports, import defer with the defer phase, and Source Phase Imports with the source phase, so the same resource can use different loaders, parser options, or module types depending on how it is imported.

#Automatic persistent cache cleanup

Rspack's persistent cache is isolated by version. When cache.version, cache-related configuration, or the Rspack version changes, Rspack creates a new cache version to avoid reusing an incompatible cache. During long-term development, frequent branch switching, or CI workflows that reuse the working directory, old cache versions may continue to accumulate and take up disk space.

Rspack 2.1 adds an automatic cleanup mechanism for persistent cache. It uses cache.maxAge and cache.maxVersions to control old versions retained in the cache directory:

• cache.maxAge: the maximum time a cache version can remain unaccessed. The default value is 7 * 24 * 60 * 60 (7 days).
• cache.maxVersions: the maximum number of cache versions retained in the current cache directory. The default value is 3.

export default {
  cache: {
    type: 'persistent',
    maxAge: 7 * 24 * 60 * 60,
    maxVersions: 3,
  },
};

When the number of cache versions exceeds the retention limit, or when versions have not been accessed for a long time, Rspack prioritizes cleaning up older and less recently accessed cache versions. This keeps recent reusable caches while preventing the persistent cache directory from growing without bound. For scenarios where you need to manage caches manually, set maxAge or maxVersions to Infinity to disable age-based or version-count-based cleanup respectively.

#Output optimization

#pureFunctions stabilized

Rspack 2.0 introduced the experimental pureFunctions capability for finer-grained tree shaking of side-effect-free function calls across modules. After a period of iteration and validation, Rspack 2.1 enables this capability by default in production mode, so you no longer need to manually set experiments.pureFunctions: true.

This capability mainly covers two scenarios: adding the /*#__NO_SIDE_EFFECTS__*/ annotation at function definitions, and marking side-effect-free functions through module.parser.javascript.pureFunctions. When the result of a marked function call is unused, Rspack can safely remove the call during tree shaking.

For example, the following join function is declared as side-effect-free. If the return value of the call is not used, the call is removed automatically:

/*#__NO_SIDE_EFFECTS__*/
export function join(a, b) {
  return `${a}-${b}`;
}

import { join } from './utils';

// The return value is unused, so this call is removed automatically.
join('btn', 'primary');

If you want to disable this analysis, you can disable experiments.pureFunctions:

export default {
  experiments: {
    pureFunctions: false,
  },
};

See the tree shaking guide for details.

#Branch-aware dependency pruning

Rspack 2.1 improves dependency analysis for inline constant scenarios. When the condition of an if statement or ternary expression depends on an inlined boolean export, Rspack now associates the branch condition with dependencies inside that branch. If Rspack later determines that a branch will not be executed, dependencies in that branch are marked as inactive, allowing them to participate in tree shaking and chunk pruning.

export const IS_DEV = false;

import { IS_DEV } from './env';

if (IS_DEV) {
  import('./debug-tools');
} else {
  import('./app');
}

In the example above, IS_DEV can be inlined as false, so the ./debug-tools dependency in the if branch is no longer treated as an active dependency. Compared with the previous behavior where dependencies from both branches were retained, this can reduce invalid modules in the output and avoid generating unnecessary dynamic import chunks for unreachable branches.

This optimization also supports simple boolean expressions composed with !, &&, and ||, as well as dependencies inside ternary expression branches. For conditions that cannot be statically determined, Rspack keeps the original behavior to ensure runtime semantics remain unchanged.

#Branch-aware ESM export presence checks

Rspack checks during compilation whether ESM imports access exports that do not exist and emits warnings such as export ... was not found. Previously, this check could not understand runtime existence checks such as if ("name" in ns), so even when code checked whether an export existed first, accesses inside the branch could still produce false positives.

Rspack 2.1 improves analysis for in expressions on ESM namespaces. When an export access is guarded by the same in check, Rspack recognizes the branch condition and no longer reports a missing export warning for that access.

import * as feature from './feature';

if ('debug' in feature) {
  feature.debug();
}

In the example above, if ./feature does not export debug, 'debug' in feature returns false at runtime and feature.debug() inside the branch will not be executed. Rspack can now understand this and no longer emits a missing export warning for the guarded access.

This check also applies to branch conditions composed with !, &&, ||, and ternary expressions. It supports namespace imports, namespace objects from named exports, and nested member access. For accesses that are not guarded by the same in check, Rspack continues to report warnings so real missing export issues are not hidden.

#export const value binding optimization

Rspack 2.1 simplifies the generated code for ESM export const. In previous versions, Rspack generated getter functions for ESM exports uniformly to preserve ESM live binding semantics:

__webpack_require__.d(__webpack_exports__, {
  value: () => value,
});

For export const in non-cyclic modules, however, the exported value will not change after module initialization, so it does not need to be read through a getter every time. In production builds, Rspack 2.1 uses circular module information: when Rspack confirms that the current module is not part of a circular dependency, export const is defined on the namespace object as a read-only value, reducing generated code and runtime getter call overhead.

// Before: accessing namespace.value executes a getter function.
__webpack_require__.d(__webpack_exports__, {
  value: () => value,
});

// Rspack 2.1: const exports in non-cyclic modules are defined as read-only values.
// Accessing namespace.value no longer needs to execute a getter function.
__webpack_require__.d(
  __webpack_exports__,
  {},
  {
    value: value,
  },
);

export const answer = 42;

const message = 'hello';
export { message };

export default 'default value';

The named const exports above, as well as constant values in default exports, can benefit from this optimization. For let, function exports, and const exports in cyclic modules, Rspack still keeps the getter form to ensure mutable exports and circular dependency scenarios preserve correct semantics. In the future, we will continue exploring reassignment analysis to identify more stable exports, so more scenarios can use the lighter value-binding form.

#Ecosystem

#TanStack RSC support

We are working with the TanStack team to improve Rsbuild support in TanStack Start, and we have already made concrete progress: TanStack Start now officially supports Rsbuild. Developers can now use Rsbuild to build TanStack Start applications and access framework capabilities including RSC.

Our core goal for RSC is to provide general-purpose RSC build capabilities, allowing higher-level frameworks to integrate RSC based on their own routing, rendering, and server runtime solutions while reusing unified build infrastructure.

If you want to try RSC in the Rspack stack, see:

• TanStack Start guide: learn how to use Rsbuild in TanStack Start.
• rsbuild-plugin-rsc: an RSC plugin based on Rsbuild.

#Rsbuild

Rsbuild 2.1 has been released alongside Rspack 2.1. See the Rsbuild 2.1 blog for details.

#Rslib

Rslib adds a fast type generation mode based on isolatedDeclarations. After enabling dts.isolated, Rslib uses SWC's type generation capability during the Rspack build to directly emit declaration files for TypeScript modules in the dependency graph.

import { defineConfig } from '@rslib/core';

export default defineConfig({
  lib: [
    {
      dts: {
        isolated: true,
      },
    },
  ],
});

This capability is suitable for daily builds in monorepos or multi-package libraries. You can split declaration generation and type checking into two steps:

• Daily builds: Rslib quickly emits declaration files.
• Global checks: run unified type checking in CI or a pre-commit hook through rslint --type-check.

Taking the Rsbuild repository as an example, the time required to generate declaration files with different approaches is as follows:

For more details, see dts.isolated.

#Rstest

Rstest 0.10 focuses on test efficiency and stability. The biggest update is the new --changed / --related test filtering capability, which can run only the tests affected by source changes and significantly shorten feedback loops in local development and CI for large projects.

--changed automatically detects changed source files from the Git working tree, including unstaged, staged, and untracked files, then runs only the related tests:

rstest run --changed

You can also compare against a specific commit or branch:

rstest run --changed=HEAD~1
rstest run --changed=origin/main

--related lets you explicitly pass source files and run only tests that depend on them. It also provides the Jest-compatible --findRelatedTests alias:

rstest run --related src/button.ts
rstest run --findRelatedTests src/button.ts

If you only want to preview the affected test files, combine these flags with rstest list:

rstest list --changed --filesOnly
rstest list --related src/button.ts --filesOnly

Rstest 0.10 also includes several other improvements:

• A new threads pool based on worker_threads, reducing startup overhead for suites with many small test files.
• Persistent build cache support, improving warm-run build performance.
• Memory-aware worker scheduling, reducing OOM risk under high parallelism.
• Silent console output for passed tests, keeping failure logs useful while reducing noise.
• --trace profiling support, making performance investigation easier.
• Clearer worker output attribution for logs and crashes.

See the Rstest 0.10 blog for details.

#Rslint

Many built-in rules: Rslint has ported rules from ESLint core and community plugins such as @typescript-eslint, react, jsx-a11y, jest, and promise. It now has more than 400 built-in rules, covering common rules out of the box.

ESLint plugin compatibility: beyond built-in rules, Rslint can now directly run rules from community ESLint plugins and use them together with built-in native rules. You only need to mount the plugin under a custom prefix in the configuration. Diagnostics from the plugin are merged into the same report, autofixes can be applied together through --fix and the editor's source.fixAll, and the behavior is consistent between the CLI and the VS Code extension.

import examplePlugin from 'eslint-plugin-example';

export default [
  {
    files: ['**/*.ts'],
    plugins: { example: examplePlugin },
    rules: {
      'example/some-rule': 'error',
    },
  },
];

For more usage and current limitations, see the ESLint plugin compatibility guide.

#Rspress

Rspress now provides more Agent Skills, including:

• rspress-docs-generator: generate an Rspress documentation site for the current project.
• rspress-custom-theme: generate a custom Rspress theme.

Here is a theme generated by rspress-custom-theme:

These skills can be installed directly into existing projects or selected during project initialization. For more details, see the Rspress - AI Guide.

#Rsdoctor

Rsdoctor added AI analysis in GitHub Actions. When a build analysis report contains size changes, Rsdoctor can combine them with the current project's build data to analyze regressions and help locate performance bottlenecks, bundle size increases, and optimization opportunities.

#rspack-merge

We released rspack-merge, an npm package for merging Rspack configurations. It covers use cases ranging from composing base configurations to merging loader and plugin rules.

import { defineConfig } from '@rspack/cli';
import { merge } from 'rspack-merge';

const sharedConfig = defineConfig({
  // ...
});

const serverConfig = merge(sharedConfig, {
  // ...
});

const clientConfig = merge(sharedConfig, {
  // ...
});

export default [serverConfig, clientConfig];

rspack-merge is written in TypeScript, ships modern ESM output, and keeps zero runtime dependencies, making configuration merging simple, reliable, and lightweight.