April 22, 2026

#Announcing Rspack 2.0

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

#Looking back at 1.x

When we released Rspack 1.0 in August 2024, we set a clear goal: deliver a 10x performance improvement while staying compatible with the webpack API and ecosystem.

Looking back at the 1.x cycle, we have largely achieved that goal. Rspack not only implemented webpack's core capabilities and plugin APIs, but also continued to improve developer experience, output optimization, and support for modern language features. Along the way, we introduced and refined incremental builds, lazy compilation, persistent cache, constant inlining, virtual modules, barrel file optimization, and more.

Rspack is also being adopted by a growing number of users. Compared with the 1.0 release, Rspack's weekly downloads have grown from 100,000 to 5 million:

We also built Rstack around Rspack, a unified JavaScript toolchain that includes Rsbuild, Rslib, Rstest, Rspress, Rsdoctor, and Rslint. These tools serve different use cases, but they share the same mission: making web development simpler, more consistent, and more efficient.

Rspack is also becoming part of the broader JavaScript ecosystem. Many excellent tools, frameworks, and platforms in the community now support Rspack, including Angular Rspack, Addfox, Docusaurus, Extension.js, ice.js, Lynx, Meteor, Modern.js, Next.js, Nuxt, Nx, Kmi, Re.Pack, Remotion, Shakapacker, Storybook, TanStack Router, Unplugin, Vize, xmcp, and Zephyr. We sincerely thank all the projects and teams in the community that support Rspack.

#Toward 2.0

The JavaScript ecosystem keeps evolving, and coding agents are also changing how software is built. This prompted us to rethink how a future-ready bundler should evolve.

Rspack's goal is not just to be a faster webpack. During the 1.x cycle, we intentionally aligned Rspack's APIs and defaults with webpack 5 to help existing projects migrate at minimal cost. But as JavaScript modules and the surrounding ecosystem continue to evolve, some historical design choices are no longer the right defaults for modern development.

Starting in 2.0, while remaining compatible with the webpack ecosystem, Rspack will gradually introduce defaults, API design, and build outputs that are better aligned with modern JavaScript development. We will roll out these changes in stages. We will avoid packing too many breaking changes into a single major release whenever possible, and we will provide migration guides and Agent Skills to keep migration costs manageable.

#Highlights in 2.0

Rspack 2.0 brings the following updates:

• Performance improvements
  • Faster builds
  • Fewer default dependencies
• Output optimization
  • Better static analysis
  • Compiler annotation support
  • Module Federation tree shaking
• Improved ESM support
  • Pure ESM packages
  • Support for import.meta
  • Support for import defer
  • Improved ESM library builds
• New features
  • React Server Components support
  • Support for #/ subpath alias imports
  • Simplified target configuration
  • Simplified swc-loader configuration
  • Control over CSS imports
  • Use hashes as module IDs
  • Improved code splitting

#Performance improvements

#Faster builds

Build performance has always been one of Rspack's core priorities. Compared with Rspack 1.7, Rspack 2.0 improves overall performance by around 10%, and by as much as 100% compared with 1.0.

Data source: rspack-react-10k-benchmark

These improvements mainly come from continued optimization of the core architecture. We refactored parts of the algorithms and data structures on critical performance paths, upgraded outdated dependencies, and removed unused code paths.

With persistent cache enabled, both build performance and memory usage improve even further:

• Rspack now supports cache reuse for the SWC minimizer plugin. On cache hits, build performance improves by around 50%.
• With optimized underlying storage, memory usage drops by more than 20% when cache is enabled.

#Fewer default dependencies

Rspack 2.0 reduces the number of npm dependencies installed by default:

• @rspack/dev-server: dependency count reduced from 192 to 1.
• @rspack/core: dependency count reduced from 8 to 1.
• @rspack/cli: now has zero dependencies.

In Rspack 1.x, @rspack/dev-server pulled in many dependencies indirectly through webpack-dev-server, which increased the installation size and made dependency management more complex. To address this, we refactored it, streamlined its features and dependencies, and reduced the install size by more than 90% (from 15 MB to 1.4 MB).

At the same time, @rspack/cli no longer depends on @rspack/dev-server by default. That means if you only use rspack build, you no longer need to install dev-server-related dependencies.

We also reduced dependencies through the following measures:

• Making non-core dependencies optional. For example, @module-federation/runtime-tools now only needs to be installed when you use the ModuleFederationPlugin.
• Replacing heavier dependencies with lighter alternatives, such as using connect-next instead of Express. For dev servers, Connect's middleware model already covers most scenarios, and using it also keeps Rspack aligned with Rsbuild's dev server implementation.
• Bundling some dependencies into the npm package so that Rspack can control the versions of those dependencies and their transitive dependencies, reducing potential supply-chain risks caused by automatic upgrades.
• Preferring native Node.js 20+ APIs where possible, such as using styleText instead of picocolors.

#Output optimization

#Better static analysis

Rspack 2.0 improves static analysis so that more complex code patterns can benefit from tree shaking. Some patterns that were previously difficult to analyze can now participate in export-level pruning.

• CommonJS require destructuring: Rspack can now identify which exported members are actually used in a destructuring assignment and keep only the required code.

const { bar } = require('./foo');

• CommonJS require property access and calls: Rspack can now further analyze property access and calls to determine which exports are used.

const foo = require('./foo');

foo.bar;
foo.baz();

• Inline property access and calls on dynamic import() results: When module members are accessed directly in the expression, Rspack can also identify the used exports and prune the rest.

(await import('./foo')).bar;

#Compiler annotation support

Rspack 2.0 now supports compiler annotations, allowing you to use #__NO_SIDE_EFFECTS__ to mark functions as side-effect-free. When the return value of such a function call is unused, tree shaking can automatically remove the unused code.

For example, in the following code, join is marked as side-effect-free. When its return value is not used, the call can be removed safely.

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

import { join } from './utils';

join('btn', 'primary');

This feature is still experimental and currently requires experiments.pureFunctions to be enabled. It will be enabled by default in a future version. See the guide for details.

For third-party modules whose source code you cannot modify directly, Rspack also lets you manually declare pure functions through module.parser.javascript.pureFunctions to achieve the same effect.

export default {
  module: {
    parser: {
      javascript: {
        pureFunctions: ['myFunctionName'],
      },
    },
  },
};

#Module Federation tree shaking

Rspack now supports tree shaking for shared dependencies in Module Federation, allowing it to prune them at the export level, remove unused parts, and reduce the size of shared packages.

In Rspack 1.x, once a dependency was declared as shared, the runtime usually had to load the entire package. Even if only a few exports were used, the whole package would still be included. For large shared libraries, that could add significant overhead.

Rspack 2.0 adds treeShaking support to the shared option. When enabled, ModuleFederationPlugin generates a pruned build for the shared dependency and loads that result at runtime when possible. If it cannot be used, Rspack falls back to the full dependency to keep behavior consistent.

For example:

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

export default {
  plugins: [
    new rspack.container.ModuleFederationPlugin({
      shared: {
        'lodash-es': {
          singleton: true,
          treeShaking: {
            mode: 'runtime-infer',
            usedExports: ['debounce'],
          },
        },
      },
    }),
  ],
};

See the shared dependency tree shaking guide for more details.

#Improved ESM support

#Pure ESM packages

Rspack's core packages are now published as pure ESM packages, and their CommonJS builds have been removed. This makes module loading more consistent and better aligned with current Node.js practices.

This change affects the following npm packages:

• @rspack/core
• @rspack/cli
• @rspack/dev-server
• @rspack/plugin-react-refresh

In Node.js 20 and later, the runtime already supports loading ESM modules using require(esm). For most projects that still use Rspack through the JavaScript API, this change has little practical impact and does not require additional code changes.

#Support for import.meta

Rspack 2.0 improves support for import.meta.

In Rspack 1.x, to support non-ESM output, Rspack resolved import.meta during compilation and replaced it with corresponding values. Unknown import.meta properties were usually replaced directly with undefined.

Starting in Rspack 2.0, when generating ESM output, Rspack preserves unknown import.meta properties by default instead of replacing them during compilation. This lets you use custom import.meta properties and makes the behavior closer to the ESM spec.

You can also control this behavior with module.parser.javascript.importMeta, for example:

export default {
  output: {
    module: true,
  },
  module: {
    parser: {
      javascript: {
        importMeta: 'preserve-unknown',
      },
    },
  },
};

Rspack 2.0 also adds support for import.meta.main, import.meta.filename, and import.meta.dirname.

#Support for import defer

import defer is a JavaScript feature for deferring module evaluation, and it is also supported in TypeScript 5.9. It allows a module to be loaded without immediately evaluating it or its dependencies, giving you more control over when code runs and when side effects occur.

Rspack has supported the import defer * as foo from './foo' syntax since 1.6. In 2.0, we expanded that support to include import.defer(), allowing it to cover more real-world scenarios.

• Enable the experimental flag:

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

• Use import.defer() to dynamically import a module:

const file = Math.random() > 0.5 ? 'a.js' : 'b.js';

import.defer('./dir' + file);

#Improved ESM library builds

When building JavaScript libraries, the quality of ESM output directly affects how well downstream tools can analyze and optimize it. Cleaner ESM output is usually better for static analysis, code splitting, and tree shaking.

In Rspack 2.0, you can set output.library.type to 'modern-module' to generate ESM output that is better suited to published libraries.

export default {
  output: {
    library: {
      type: 'modern-module',
    },
  },
};

Compared with output.module, which targets general ESM output, modern-module is specifically optimized for library builds. It evolved from the experimental rspack.experiments.EsmLibraryPlugin introduced in Rspack 1.x and produces output that is easier for downstream tools to analyze and process. In code-splitting scenarios, it also preserves a cleaner ESM structure and reduces duplicated code in multi-entry builds.

In addition, modern-module supports preserving the source directory structure. See the ESM guide for details.

#New features

#React Server Components support

React Server Components (RSC) are becoming an important foundation for full-stack React frameworks. Rspack 2.0 now provides experimental low-level build support, including:

• Directive support: Handles "use client" as well as module-level and function-level "use server" directives.
• Compile-time checks: Detects React API usage that violates RSC rules during compilation, helping catch issues before they reach runtime.
• CSS support: Collects styles from server and client components during the build and injects them during rendering.
• HMR support: Supports hot updates for both server and client components.

You can use this capability in two ways:

• Use Rsbuild: We provide out-of-the-box RSC support through rsbuild-plugin-rsc.
• Configure Rspack manually: Refer to the React Server Components documentation to add the required configuration yourself.

Across the ecosystem, Modern.js already provides RSC support built on Rspack. See the Modern.js RSC documentation for details. Rspack also supports React Router's Data Mode, with examples available in the React Router examples.

We're also working with the TanStack team and plan to support TanStack Start and TanStack's RSC in future releases. TanStack Start is a full-stack framework built on TanStack Router, and we're excited to explore more possibilities for RSC together.

#Support for #/ subpath alias imports

Rspack 2.0 supports #/ subpath alias imports during module resolution. This lets you use the imports field in package.json directly to organize internal path mappings, without maintaining a separate alias configuration.

{
  "imports": {
    "#/*": "./src/*"
  }
}

import main from '#/main.ts';

#Simplified target configuration

In Rspack 1.x, the top-level target option did not affect the transformation targets used by loaders or minifiers. As a result, you often had to configure target environments separately in loaders and minimizer plugins, which increased configuration overhead and duplicated the same information in multiple places.

Rspack 2.0 improves this behavior. Built-in loaders and minimizer plugins now read the top-level target configuration by default and infer their own target environments from it. In most cases, you only need to declare the target once at the top level to keep JavaScript transforms, CSS transforms, and minification aligned.

export default {
  target: 'browserslist: Chrome >= 100',
  module: {
    rules: [
      {
        test: /\.js$/,
        use: [
          {
            loader: 'builtin:swc-loader',
            options: {
              env: { targets: 'Chrome >= 100' },
            },
          },
        ],
      },
    ],
  },
  optimization: {
    minimizer: [
      new rspack.SwcJsMinimizerRspackPlugin(),
      new rspack.LightningCssMinimizerRspackPlugin({
        minimizerOptions: { targets: 'Chrome >= 100' },
      }),
    ],
  },
};

See target - Target inheritance for more details.

#Simplified swc-loader configuration

In earlier versions, if you wanted builtin:swc-loader to handle .js, .jsx, .ts, .tsx, and similar files in a single rule, you had to explicitly set options such as syntax, jsx, and tsx in jsc.parser based on the file type. This ensured that SWC could parse each file with the correct semantics, such as deciding whether < should be treated as JSX syntax or a TypeScript generic.

That added extra configuration complexity. To make SWC parse files with different extensions correctly, you often needed multiple rules, which made the config longer and harder to maintain.

To solve this, Rspack 2.0 introduces the detectSyntax option in the built-in swc-loader. With detectSyntax: 'auto', the loader automatically infers parser options such as syntax, jsx, and tsx from the file extension. A single rule can now cover multiple file types, making the configuration much cleaner.

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

#Control over CSS imports

Rspack 2.0's CSS parser provides the resolveImport option to control whether @import is resolved and inlined during the build.

By default, Rspack resolves @import and merges the imported content directly into the current file. You can also set resolveImport to false to preserve the original @import and leave it to the browser or downstream tools.

resolveImport also accepts a function, allowing you to decide whether each @import should be inlined. For example, you can inline only imports whose filename contains style.css, while leaving other imports unchanged:

export default {
  module: {
    parser: {
      'css/auto': {
        resolveImport: ({ url }) => url.includes('style.css'),
      },
    },
  },
};

#Use hashes as module IDs

Rspack 2.0 adds a new hashed option to optimization.moduleIds. When enabled, Rspack generates short, stable hashes from module paths and uses them as module IDs.

This is useful when you want module IDs to remain stable while also shortening them. For large applications with many modules, it can also reduce their footprint in the output in some cases.

export default {
  optimization: {
    moduleIds: 'hashed',
  },
};

#Improved code splitting

Rspack 2.0 now supports splitChunks.enforceSizeThreshold, which lets you define a size threshold that Rspack will enforce during code splitting.

By default, request-count limits in splitChunks, such as maxAsyncRequests and maxInitialRequests, can prevent large chunks from being split further. With enforceSizeThreshold enabled, once a module group exceeds the configured threshold, Rspack ignores those limits and forces the split.

In production mode, Rspack sets a default enforceSizeThreshold of 50000 bytes for all module types. In other modes, the default is 30000 bytes. You can also adjust it as needed:

export default {
  optimization: {
    splitChunks: {
      // Applies to all module types
      enforceSizeThreshold: 50000,
      // You can also configure it per module type
      // enforceSizeThreshold: { javascript: 50000, css: 30000 },
    },
  },
};

This option can also be configured separately in cache groups, so different cache groups can use different thresholds.

#Try 2.0

#Create a new project

If you are trying Rspack for the first time, we recommend creating an Rsbuild project directly. It is an out-of-the-box build tool powered by Rspack:

npm create rsbuild@latest

See the Quick Start for more details.

#Upgrade from v1

Rspack 2.0 includes some breaking changes. For existing projects, we provide an Upgrade Guide that covers all breaking changes from v1 to v2 and how to migrate them.

If you use a coding agent that supports Skills, you can install the following Skill and let the agent help with the migration. In most cases, this is more efficient than upgrading manually.

npx skills add rstackjs/agent-skills --skill rspack-v2-upgrade

#Looking ahead

Rspack 2.0 marks a new stage in the project's evolution. Since 1.0, it has introduced a series of updates to its performance, API design, and build outputs. Looking forward, we will continue pushing Rspack forward in many directions, including output optimization, agent support, and toolchain collaboration.

• Output optimization: Rspack's goal is not only to speed up builds, but also to generate higher-quality outputs while keeping behavior stable. We will continue improving core capabilities such as tree shaking, code splitting, and static analysis, explore optimizations based on static type information, and provide finer-grained controls for code splitting and optimization.
• Agent-friendly: As coding agents become an increasingly important user group, we will incorporate these use cases more broadly into Rspack's design so agents can understand and handle build issues more easily. For example, we will expose richer debugging information, performance metrics, and other context through the CLI, so agents can analyze problems more accurately and assist with debugging and optimization.
• Toolchain collaboration: In real-world projects, bundling is only one part of the overall workflow. Testing, type checking, and linting can also add significant overhead. We will continue evolving the Rstack toolchain as a coordinated system and deepen its integration with typescript-go. For example, Rslint already supports rslint --type-check, which runs linting and type checking together. We also plan to add typescript-go support to ts-checker-rspack-plugin.

See Rspack Roadmap for more details.

#FAQ

#Will Rspack 2.0 still be compatible with webpack?

Yes. In the 2.0 era, compatibility with the webpack ecosystem will remain an important goal for Rspack.

As JavaScript standards continue to evolve, Rspack will also adopt better defaults and API design more proactively. This will happen gradually.

#Will the 1.x line continue to be maintained?

Yes. After the 2.0 release, we will continue to maintain the 1.x line for a period of time, including fixes for critical issues and migration support. However, new features and optimizations will be prioritized in 2.x, so we recommend upgrading to 2.x as soon as possible.

#When will the Rspack ecosystem upgrade to 2.0?

Rsbuild 2.0 has been released alongside Rspack 2.0. See the Rsbuild 2.0 announcement for more details.

Rslib, Rstest, and Rspress will also upgrade to Rspack 2.0 soon. At the same time, we will continue helping frameworks and tools in the community upgrade and adapt to Rspack 2.0.

#Acknowledgements

We would like like to thank all Rspack users, contributors, and partners. Every piece of feedback and every contribution has helped move the Rspack ecosystem forward. We also hope that Rspack can continue to contribute to the broader JavaScript ecosystem.

We are equally grateful to the teams behind other bundlers in the community, including esbuild, Parcel, Rollup, Rolldown, Turbopack, and webpack. Their ongoing exploration in different directions has continued to inspire new ideas across the ecosystem, and has helped turn many of them into reality.

December 31, 2025

#Announcing Rspack 1.7

We are excited to announce Rspack 1.7! This marks the final minor release in the Rspack 1.x series and focuses on stabilizing existing features. Next, we'll be moving toward Rspack 2.0.

Notable changes include:

• New features
  • Improved SWC plugin compatibility
  • Importing assets as bytes
  • Lazy compilation
  • Experimental features stabilized
• Rstack progress
  • Rsbuild 1.7
  • Rsdoctor 1.4
  • Rslib 0.19
  • Rstest 0.7
  • Rspress 2.0 RC

#New features

#Improved SWC plugin compatibility

In previous versions, the upgrade cost for SWC Wasm plugins was relatively high. This was because the SWC AST structure evolved across versions, causing existing plugins to fail after an SWC upgrade. Plugin authors needed to adapt their plugins, and users needed to upgrade their dependencies in lockstep, which affected project stability and the upgrade experience.

To address this issue, we contributed a series of compatibility improvements to the SWC community, including:

• Using the self-describing cbor serialization scheme to replace the version-sensitive rkyv, allowing Wasm plugins to better adapt to AST structure changes.
• Introducing the Unknown variant for enum types in the AST, improving fault tolerance when encountering new fields or nodes.

In Rspack 1.7, we upgraded the SWC version in use and adopted these compatibility improvements. From now on, in most scenarios, SWC upgrades are unlikely to break existing plugins built with older SWC versions.

Currently, this approach has been adopted by most popular SWC Wasm plugins. If you are an SWC Wasm plugin author, refer to the official guide to adopt these changes and reduce maintenance costs in future version evolutions.

#Importing assets as bytes

Rspack now natively supports the Import Bytes proposal for importing assets as bytes. You can now import assets as Uint8Array and decode them with TextDecoder.

// Static import
import fileBytes from './file.bin' with { type: 'bytes' };
const decoder = new TextDecoder('utf-8');
const text = decoder.decode(fileBytes);

// Dynamic import
const module = await import('./file.bin', { with: { type: 'bytes' } });
const decoder = new TextDecoder('utf-8');
const text = decoder.decode(module.default);

#Lazy compilation

In Rspack 1.5, we stabilized the Lazy Compilation feature and enabled it by default for dynamically imported modules in Rsbuild.

Starting from Rspack 1.7, the Rspack CLI also enables lazy compilation by default for dynamically imported modules when building web applications. This change reduces the number of modules in the initial build, thereby speeding up the dev server startup.

export default {
  // Current default configuration
  lazyCompilation: {
    imports: true,
    entries: false,
  },
};

If you have special requirements, such as needing to debug the full build output or inspect the complete module graph, you can explicitly disable this feature by setting lazyCompilation to false.

#Experimental features stabilized

In Rspack 1.7, we have stabilized several experimental features. The following capabilities have been verified in production and are now considered stable, and the corresponding experimental flags have been deprecated or enabled by default:

• Constant Inlining Optimization: This optimization is now stable and enabled by default in production builds.
  • The original experiments.inlineConst option is deprecated.
  • If you need to disable this behavior, use optimization.inlineExports to control it.
• TypeScript Enum Inlining Optimization: This optimization is now stable.
  • The original experiments.inlineEnum option is deprecated.
  • Use collectTypeScriptInfo.exportedEnum to control whether to collect exported enum information.
  • Use optimization.inlineExports to control whether to inline enum.
• Type Re-export Check: This optimization is now stable.
  • The original experiments.typeReexportsPresence option is deprecated.

Refer to the Upgrade Guide to learn how to adjust related configurations.

#Rstack progress

#Rsbuild 1.7

#Error overlay improvements

Rsbuild's error overlay now supports displaying runtime errors. When an exception is thrown during application execution, the error will be rendered directly on the overlay, helping you identify and diagnose issues faster.

This feature is disabled by default and can be enabled via the dev.client.overlay.runtime option:

export default {
  dev: {
    client: {
      overlay: {
        runtime: true,
      },
    },
  },
};

#Asset size diff reporting

Rsbuild now supports reporting size differences to see whether the build output size has changed.

When the performance.printFileSize.diff option is enabled, Rsbuild records a snapshot of the asset sizes upon build completion. Subsequent builds will automatically compare with the previous result and display size deltas in the logs. You can clearly see whether each file has grown or shrunk, as well as the overall size change, making it suitable for quickly spotting size regressions during daily development.

export default {
  performance: {
    printFileSize: {
      diff: true,
    },
  },
};

#create-rsbuild improvements

create-rsbuild now includes more out-of-the-box tools.

When creating an Rsbuild project, you can now choose to automatically integrate Rstest as the testing framework or enable Storybook for UI component development and debugging. Related dependencies and configurations will be set up during initialization, reducing repetitive manual configuration costs.

◆  Select additional tools (Use <space> to select, <enter> to continue)
│  ◼ Rstest - testing
│  ◻ Biome - linting & formatting
│  ◻ ESLint - linting
│  ◻ Prettier - formatting
│  ◻ Storybook - component development
└

#Rsdoctor 1.4

#New treemap view

Rsdoctor 1.4 introduces an improved Treemap view. The new interaction design helps you analyze the overall composition of the bundle and the size proportion of various assets and modules more intuitively.

In this view, you can quickly locate specific modules or assets via search. Clicking on a module or asset will automatically focus and zoom in on the corresponding area. Double-clicking a module can also expand its dependency chain, allowing you to view the reference relationship between modules layer by layer, helping identify where the size comes from.

#Rslib 0.19

#ESM output stabilization

In previous versions, Rslib enabled Rspack's new ESM library output through the experimental configuration experiments.advancedEsm to improve the quality of ESM output. After verification and polishing over multiple versions, this capability is now stable.

Starting from Rslib 0.19, Rslib's bundle mode enables this feature by default. Developers do not need any additional configuration to directly obtain ESM artifacts that are friendly to static analysis and fully support code splitting.

#JavaScript API

Rslib 0.19 introduces a JavaScript API, allowing developers to invoke Rslib's build capabilities programmatically in JavaScript code.

Here is a basic example:

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

// Create Rslib instance
const rslib = await createRslib();
// Build production output
await rslib.build();

For more usage, refer to the API Documentation.

#Rstest 0.7

#Configuration adapters

Rstest 0.7 introduces the extends option and an adapter mechanism, allowing you to directly reuse existing tool or framework configurations. An adapter is a configuration transformation function that can convert configurations from other tools into Rstest configurations, thereby reducing the integration overhead of Rstest.

For example, in a library project using Rslib, you can directly reuse the existing Rslib configuration via the @rstest/adapter-rslib adapter:

import { defineConfig } from '@rstest/core';
import { withRslibConfig } from '@rstest/adapter-rslib';

export default defineConfig({
  // Automatically read rslib.config.ts and convert to Rstest configuration
  extends: withRslibConfig(),
  // Other test configurations
  coverage: {
    // ...
  },
});

The adapter is responsible for converting configurations of different tools into Rstest configurations (such as define, alias, etc.), while extends is responsible for merging the converted configuration with Rstest's configuration. By combining the two, any tool or framework based on Rspack can be integrated with Rstest at minimal cost.

Currently, the @rstest/adapter-rslib adapter has been officially released, and we will launch more adapters to interface with various tools in the Rstack. You can also refer to Rstest - Adapters to write custom adapters.

#Improved test feedback

Rstest has made several usability improvements for local development and debugging scenarios, making test feedback more intuitive:

• Spot stuck tests earlier: Rstest now supports marking test cases that have not completed for a long time during local runs. When the test process slows down, you can directly see which case is executing and may be stuck, instead of waiting blindly for the test to time out.

• Clearer timeout failure feedback: When a test fails due to timeout, Rstest now displays the number of executed assertions in the error message. This helps you quickly judge whether the test has been partially executed or is stuck in some asynchronous logic, thus locating the problem faster.

#Rspress 2.0 RC

#SSG-MD feature

In front-end frameworks that rely on dynamic React rendering, static information is often difficult to extract, and Rspress also encountered the same problem. Rspress allows users to enhance document expressiveness through dynamic features such as MDX fragments, React components, Hooks, and TSX routes. However, these dynamic contents face several challenges when converted to Markdown text:

• Directly inputting MDX to AI will contain a lot of code syntax noise and lose React component content.
• Converting SSG-generated HTML to Markdown often yields poor results, and information quality is difficult to guarantee.

To solve this problem, Rspress 2.0 introduces the SSG-MD feature. This is a new rendering mode, as the name suggests, the key difference from traditional Static Site Generation (SSG) is that it renders your page into Markdown files instead of HTML files, and generates llms.txt and llms-full.txt files. Compared to traditional approaches such as converting HTML to Markdown, SSG-MD has better information sources during rendering, such as React Virtual DOM, so it produces higher-quality static content with greater flexibility.

Enabling it is very simple:

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

export default defineConfig({
  llms: true,
});

The build will generate the following structure:

doc_build
├── llms.txt          # Summary version, containing key document index
├── llms-full.txt     # Full version, containing all document content
├── guide
│   └── start
│       └── introduction.md
└── ...

For custom components, you can control their rendering behavior in SSG-MD mode via environment variables:

export function Tab({ label }: { label: string }) {
  if (import.meta.env.SSG_MD) {
    // Output plain text description in SSG-MD mode
    return <>{`**Tab: ${label}**`}</>;
  }
  // Normal interactive component rendering
  return <div className="tab">{label}</div>;
}

This preserves the interactive experience of the document and helps AI understand the semantic information of the components.

For more details, refer to: SSG-MD Guide

#Upgrade guide

#Upgrade SWC plugins

If your project uses SWC Wasm plugins (such as @swc/plugin-emotion, etc.), upgrade the plugins to be compatible with swc_core@54 or above, otherwise build failures or runtime exceptions may occur due to version incompatibility.

For details, see FAQ - SWC plugin version mismatch.

#Remove deprecated configuration

• The following experimental options have been deprecated and can be directly removed:

export default {
  experiments: {
    inlineConst: true,
    inlineEnum: true,
    typeReexportsPresence: true,
  },
};

• Adjust the position of the collectTypeScriptInfo option in builtin:swc-loader, removing the rspackExperiments level:

export default {
  module: {
    rules: [
      {
        test: /\.ts$/,
        loader: 'builtin:swc-loader',
        options: {
          rspackExperiments: {
            collectTypeScriptInfo: {
              exportedEnum: true,
              typeExports: true,
            },
          },
        },
      },
    ],
  },
};

October 30, 2025

#Announcing Rspack 1.6

We are excited to announce Rspack 1.6!

Notable changes include:

• New Features
  • Enhanced tree shaking
  • Support for import defer
  • Improved ESM output
  • Optimized barrels by default
  • Stabilized layers feature
  • Preserve JSX syntax
  • Extract source map
  • Performance improvements
• Rstack Progress
  • Rsbuild 1.6
  • Rspress v2 beta
  • Rslib 0.16
  • Rstest 0.6
  • Rsdoctor 1.3
• Ecosystem
  • next-rspack

#New features

#Enhanced tree shaking

Rspack 1.6 improved tree shaking support for dynamic imports. In previous versions, Rspack could only perform tree shaking on destructured assignments within dynamic imports, while other import patterns were not analyzed.

Now, Rspack introduces comprehensive static analysis for dynamic imports. It can recognize and handle a wider range of usage patterns. This allows Rspack to precisely eliminate unused exports and further reduce the size of the final bundle.

// Rspack 1.5 – Only supported destructured imports
const { value } = await import('./module');
console.log(value);

// Rspack 1.6 – Now supports the following cases
// Case 1
const mod = await import('./module');
const { value } = mod;
console.log(value);

// Case 2
const mod = await import('./module');
console.log(mod.value);

// Case 3
import('./module').then(({ value }) => {
  console.log(value);
});

// Case 4
import('./module').then((mod) => {
  const { value } = mod;
  console.log(value);
});

// Case 5
import('./module').then((mod) => {
  console.log(mod.value);
});

#Support for import defer

Rspack now supports the import defer syntax.

import defer is a new feature in JavaScript, which is also supported in TypeScript 5.9. It allows you to import a module without immediately executing the module and its dependencies, giving you better control over when code execution and side effects occur.

import defer * as foo from './foo';

You can enable this feature through experiments.deferImport:

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

Currently, Rspack only supports the import defer syntax. The function form import.defer() will be implemented in future versions.

#Improved ESM output

Optimizing ESM output has long been one of the key challenges faced by Rspack. Previously, we relied on module concatenation to optimize ESM outputs, but that approach had several limitations:

• Impure output – The generated files contained Rspack's runtime code.
• Prone to errors – Some modules could not be correctly concatenated, leading to unexpected runtime issues.
• Limited code-splitting support – Split bundles became complex and difficult to analyze or optimize statically.

To address these issues once and for all, we introduced an experimental plugin called EsmLibraryPlugin, purpose-built for constructing clean and efficient ESM libraries:

• Full control over the bundling process – All modules are linked during compilation, eliminating reliance on Rspack's runtime.
• Code-splitting support – Code after splitting can be statically analyzed and is tree-shaking friendly.

The image below compares the code splitting output before and after using this plugin — the left side shows the previous output, while the right side shows the cleaner output produced by EsmLibraryPlugin:

The EsmLibraryPlugin is now largely complete and is being integrated into Rslib to provide an out-of-the-box experience. You can also enable it manually with the following configuration:

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

export default {
  plugins: [new rspack.experiments.EsmLibraryPlugin()],
  optimization: {
    // Recommended to enable; otherwise, consumers must import runtime code from the entry.
    runtimeChunk: true,
  },
};

In addition, we've introduced an preserveModules option that preserves the original directory structure of your source files in the output:

import path from 'node:path';

export default {
  plugins: [
    new rspack.experiments.EsmLibraryPlugin({
      preserveModules: path.resolve(import.meta.dirname, './src'),
    }),
  ],
};

#Optimized barrels by default

In Rspack 1.5, we introduced the experimental lazyBarrel optimization feature, specifically designed to improve the build performance of barrel files. After a period of production environment practice and user feedback collection, we confirmed that the lazyBarrel feature has reached a stable state, so it is enabled by default in Rspack 1.6.

#Stabilized layers feature

Layer is a feature for organizing modules into different layers, which can be useful in advanced scenarios such as React Server Components. By assigning different layers to modules, you can gain finer control over their build behavior, for example:

• Compiling modules in different layers for different target environments
• Outputting them to separate build directories

Starting from Rspack 1.6, the layer feature has become stable enough that the experimental flag experiments.layers has been deprecated. You can now use the layer feature directly without the experimental flag.

For more details and practical examples, check out our new Layer guide.

#Preserve JSX syntax

Rspack now supports preserving JSX syntax in the build output. When this option is enabled, Rspack only parses JSX syntax without transforming it into JavaScript.

This feature is especially useful when building libraries that rely on JSX. For example, when using Rslib to build a component library, you can choose to keep the JSX code as-is in the output, allowing the consumer to handle the final JSX transformation during usage.

export default {
  module: {
    parser: {
      javascript: {
        jsx: true, // Enable JSX parsing
      },
    },
    rules: [
      {
        test: /\.jsx?$/,
        use: {
          loader: 'builtin:swc-loader',
          options: {
            jsc: {
              parser: { jsx: true },
              transform: {
                // Preserve JSX syntax
                react: { runtime: 'preserve' },
              },
            },
          },
        },
      },
    ],
  },
};

#Extract source map

Rspack now supports extracting existing source map data from files (from their //# sourceMappingURL comments) through rules[].extractSourceMap. This feature is particularly useful for preserving source maps provided by third-party libraries, ensuring that debugging information remains accurate even when these libraries are bundled or transformed.

This feature was introduced as a built-in alternative to source-map-loader, providing better performance and tighter integration with the build process.

export default {
  module: {
    rules: [
      {
        test: /\.m?js$/,
        extractSourceMap: true,
      },
    ],
  },
};

#Performance improvements

Rspack 1.6 introduces several performance optimizations. Compared with Rspack 1.5.0, you can expect the following improvements:

• CLI startup is about 50 ms faster
• Building 10000 React components is 11% faster
• Building multiple UI component libraries is 31% faster (thanks to the newly enabled barrel-file optimization by default)

Data source: Rspack benchmark

#Rstack progress

Rstack is a unified JavaScript toolchain centered around Rspack, featuring excellent performance and consistent architecture.

#Rsbuild 1.6

#Forward browser logs

Rsbuild now automatically forwards error logs from the browser to the terminal, helping you conveniently view runtime errors during development. This also enables Coding Agents to obtain more complete context from terminal logs, allowing them to better analyze and locate errors.

If you don't need this feature, you can disable it by setting dev.browserLogs to false:

export default {
  dev: {
    browserLogs: false,
  },
};

#Building ESM applications

Rsbuild now supports building ES Modules format output for Web applications, simply enable output.module: true:

export default {
  output: {
    module: true,
  },
};

Once enabled, Rsbuild will no longer generate IIFE format scripts by default, but will output standard ESM format and automatically set the generated <script> tags to type="module".

#Faster configuration loading

Since Node.js 22 already natively supports TypeScript, Rsbuild now defaults to using Node.js's native loader to parse configuration files; if loading fails, it will automatically fall back to Jiti. When using Node.js 22 and above, this mechanism ensures that module resolution behavior remains consistent with Node.js native behavior while providing better loading performance.

You can also manually specify the loading method through the Rsbuild CLI's --config-loader option:

# Force use of native loading
rsbuild build --config-loader native

# Force use of jiti loading
rsbuild build --config-loader jiti

#Rspress v2 beta

#New theme preview

Rspress's new theme has entered preview phase and is now live on the v2 website. 🎉

The new theme has been comprehensively upgraded in design, bringing a better documentation reading experience. It also exposes more theme APIs and CSS class names, making it easier for developers to customize the UI.

👉 Visit the Rspress v2 website to try it out.

#Sub-page switching

Rspress v2 introduces the PageTabs component, allowing you to create multiple sub-tabs within a single page. This helps naturally split long content into well-structured subpages.

#Rslib 0.16

#Faster type generation

Rslib now supports generating type declaration files based on typescript-go. By simply enabling dts.tsgo, you can boost type checking and declaration generation performance by around 300%, with even greater benefits in large projects.

export default {
  lib: [
    {
      dts: { tsgo: true },
    },
  ],
};

#Preserve JSX syntax

Rslib now supports preserving original JSX in build output, simply set runtime to 'preserve'. In this mode, JSX syntax will be preserved as-is without any transformation, making it convenient for subsequent processing by other bundling tools.

import { pluginReact } from '@rsbuild/plugin-react';

export default {
  lib: [
    {
      bundle: false,
      format: 'esm',
    },
  ],
  plugins: [
    pluginReact({
      swcReactOptions: {
        runtime: 'preserve',
      },
    }),
  ],
};

#More CLI options

Rslib supports additional CLI options in the build command, which take precedence over configuration files.

{
  "scripts": {
    "build": "rslib build --entry index.ts --minify --tsconfig tsconfig.build.json"
  }
}

This also allows you to use Rslib without a configuration file, and the CLI will automatically use a default configuration containing only a single lib and complete the build based on command line parameters.

#Rstest 0.6

#VS Code extension

The Rstest VS Code Extension is now available. It allows you to discover, run, and debug tests directly within the editor, helping you efficiently manage test cases and quickly review test results.

#Coverage support

Rstest now supports collecting code coverage using Istanbul and generating detailed coverage reports. For more information, see Rstest – Coverage.

#Rsdoctor 1.3

#Rsdoctor GitHub Actions

Rsdoctor now provides a GitHub bundle diff action, which automatically detects and compares bundle size changes during the CI phase. This helps teams identify and prevent bundle size regressions early.

#All-in-one JSON report

Rsdoctor now supports exporting a all-in-one JSON report file in Brief mode. This file can be easily stored, shared, or used for further data analysis. In addition, we’ve introduced a new Playground page, where developers can upload the JSON report to reopen and visually explore the analysis results.

#Ecosystem

#next-rspack

In Next.js 16, next-rspack has integrated Rspack's custom Rust binding solution, delivering significant performance gains:

• 24% faster build performance
• 10% faster dev performance

In this customized Rspack Rust binding, the externals logic from Next.js has been moved to the Rust side, greatly reducing communication overhead between JavaScript and Rust.

The benchmark is based on the chakra-ui-docs repository. Full performance data is available here: PERF.md.

#Upgrade guide

#Upgrade SWC plugins

If your project uses SWC Wasm plugins (such as @swc/plugin-emotion), you need to upgrade the plugins to a version compatible with swc_core@46, otherwise it may cause build errors due to version incompatibility.

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

#Remove experiments.layer

experiments.layer option has been deprecated, you can remove it directly:

export default {
-  experiments: {
-   layer: true,
-  },
};

August 26, 2025

#Announcing Rspack 1.5

We're excited to announce Rspack 1.5!

Notable changes include:

• New features
  • Barrel file optimization
  • Faster file system watcher
  • Improved browser support
  • Extending Rspack with Rust
  • Const inline optimization
  • Type re-export analysis
  • Built-in virtual modules plugin
  • Module Federation runtime hoisting
  • Installation size optimization
  • Seal phase performance optimization
• Misc
  • Drop support for Node.js 16
  • Resolver JavaScript API
• Rstack progress
  • Rslint released
  • Rsbuild 1.5
  • Rslib 0.12
  • Rspress 2.0 beta
  • Rsdoctor 1.2
  • Rstest 0.2

#New features

#Barrel file optimization

A barrel file is a common module export pattern that re-exports multiple modules through a single entry file, typically named index.js or index.ts. For example:

export { Button, Tab } from './components';
export * as utils from './utils';
export * from './hooks';

While this pattern simplifies module imports, it can introduce performance overhead during the build process: when importing a single module from a barrel file, Rspack must resolve and build all modules referenced by the barrel file, even if only a small subset is actually used.

To address this, Rspack 1.5 introduces the experimental lazyBarrel feature. This optimization automatically detects side-effect free barrel files and defers building their re-exports until actually needed. Modules are only resolved and built when actually needed, significantly reducing unnecessary module resolution and build costs.

This is particularly effective for projects with many barrel files, significantly improving build performance.

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

Real-world benchmarks show that barrel file optimization delivers substantial performance gains across applications at different scales:

• Benchmark:

• An application from ByteDance:

Barrel file optimization is enabled by default in Rsbuild 1.5, and we plan to make it the default for all projects in Rspack 1.6.

For more details, see the experiments.lazyBarrel documentation.

#Faster file system watcher

Previously, Rspack relied on the watchpack file system watcher to track file changes. However, we identified performance bottlenecks with watchpack. For example, each file change triggers the creation of a new instance, consuming significant CPU and memory in large projects (see #7490).

To address this, we built a native file system watcher in Rust, offering the following benefits:

• High performance: HMR performance improvements of up to 50%
• Incremental updates: Only processes files that actually change
• Persistent runtime: Runs continuously throughout development without reinitialization

You can try out the new watcher by enabling experiments.nativeWatcher:

export default {
  experiments: {
    nativeWatcher: true,
  },
  watchOptions: {
    // Other watch options...
  },
};

#Improved browser support

In Rspack 1.4, we officially introduced Wasm target support, enabling Rspack to run in browser-based environments powered by WebContainers, such as StackBlitz.

With the release of @rspack/browser, you can now run Rspack directly in any modern browser without relying on WebContainers or specific platforms.

@rspack/browser is designed specifically for pure browser environments, providing core bundling capabilities for web projects. It offers a lightweight way to reproduce issues, share configurations, and help developers get started with Rspack through interactive online demos.

The API of @rspack/browser is aligned with the JavaScript API of @rspack/core, with additional features and APIs tailored for browser environments.

import { rspack, builtinMemFs } from '@rspack/browser';

// Write files to memfs
builtinMemFs.volume.fromJSON({
  // ...project files
});

// Just like using JavaScript API of @rspack/core
rspack({}, (err, stats) => {
  if (err || stats.hasErrors()) {
    // ...
  }
  // Get output from memfs after bundling
  const files = builtinMemFs.volume.toJSON();
});

@rspack/browser is currently in an experimental stage and may introduce breaking changes. We will continue to enhance its capabilities for online bundling scenarios. In the meantime, Welcome to try it out at the Rspack Playground.

#Extending Rspack with Rust

You can now extend Rspack directly using Rust! With our provided repository template, you can build custom Rust plugins and loaders, and even replace Rspack's default native binding.

In JavaScript plugins, data transfer and type conversion between Rust and JavaScript can introduce performance overhead. By customizing Rspack's binding, your code can integrate directly with the Rspack Rust core, eliminating cross-language communication costs while retaining full support for all Rspack JavaScript APIs.

This approach is particularly suitable for replacing hooks that frequently interact with Rust (such as compilation.hooks.processAssets) and for compute-intensive custom loaders, where it can deliver significant build performance improvements.

Key benefits:

• Native performance — Extensions written in Rust run with the same native performance as the Rspack Rust core.
• Full compatibility — Retains all existing JavaScript APIs without requiring changes to your project.
• Developer-friendly — The official template includes a complete development environment and publishing workflow.

You can get started quickly with the official template. For more details, see the design rationale. Note that this approach introduces additional maintenance costs and is recommended only when extreme performance optimization is required.

#Const inline optimization

When organizing project code, it is common to centralize constants into files such as constants.js or, in TypeScript projects, into types.ts files containing enums.

Rspack introduces two experimental features — experiments.inlineConst and experiments.inlineEnum — that perform cross-module inlining optimizations for constants. These optimizations help minifiers perform more accurate static analysis, eliminate unused code branches, and further reduce bundle size.

For example, inlineConst can inline constants defined in leaf modules of the module graph across modules, as shown below:

// font-settings.js
export const bold = 0b001;
export const italic = 0b010;

// index.js
import { bold, italic } from './font-settings';

// MY_FONT is defined by DefinePlugin({ FONT: 0b001 })
const fontStyle = {};
if (MY_FONT & bold) fontStyle['font-weight'] = 'bold';
if (MY_FONT & italic) fontStyle['font-style'] = 'italic';
applyFont(fontStyle);

With inlineConst enabled, the if branches in the example can be clearly optimized by minifier, generating more streamlined output:

(() => {
  'use strict';
  let t = {};
  t['font-weight'] = 'bold';
  applyFont(t);
})();

For more details, see the experiments.inlineConst documentation. This feature is planned to be enabled by default in v1.6.

inlineEnum performs cross-module inlining optimization for TypeScript enums, working in a similar way to inlineConst.

// types.ts
export enum Kind {
  A,
  B,
}
// index.ts
import { Kind } from './types.ts';
console.log(Kind.A);

With inlineEnum enabled:

(() => {
  console.log(0);
})();

Note that when inlineEnum is enabled, Rspack will inline all enums by default. If you only want to inline const enums, please refer to this example.

For more details, see the experiments.inlineEnum documentation.

#Type re-export analysis

In TypeScript projects, type re-exports are a common pattern:

// index.ts
export { MyType } from './types.ts';

// types.ts
export type MyType = {
  name: string;
};

In previous versions, if you re-exported a type without adding the type modifier, Rspack could throw a warning such as: export 'MyType' (reexported as 'MyType') was not found.

This happened because Rspack processed each module in isolation. As a result, a type export (like MyType in the example) could be mistakenly treated as a value. Since no corresponding value export was found in ./types.ts, the warning was triggered.

Rspack 1.5 introduces the experiments.typeReexportsPresence option, which improves the detection of TypeScript type exports. With this option enabled, Rspack can correctly recognize type re-exports across modules, preventing false warnings.

For more details, see the experiments.typeReexportsPresence documentation.

#Built-in virtual modules plugin

In Rspack 1.4, we introduced custom InputFileSystem, which combined with the webpack-virtual-modules plugin, enabled support for virtual modules. However, this approach still had performance bottlenecks when dealing with a large number of virtual modules.

To address this, Rspack 1.5 adds a built-in VirtualModulesPlugin.

This plugin is implemented in Rust and moves the storage and management of virtual modules to the Rust layer. This reduces module read and parse overhead. As a result, it delivers significantly better performance when handling large volumes of virtual modules.

The VirtualModulesPlugin retains API compatibility with webpack-virtual-modules, making migration straightforward:

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

export default {
  plugins: [
    new rspack.experiments.VirtualModulesPlugin({
      'src/generated/config.js': 'export default { version: "1.0.0" };',
    }),
  ],
};

Thanks to our contributor @nilptr for his great work.

#Module Federation runtime hoisting

Previously, the Module Federation runtime was bootstrapped by patching the entry module. In the new version, the Module Federation plugin integrates its runtime code directly with Rspack's runtime and elevates it into the runtime chunk. This ensures that the Module Federation runtime is prepared before the application starts.

This change brings the following benefits:

1. Reduced bundle size in multi-entry scenarios
2. Fixed initialization errors related to Module Federation
3. Support for extracting the Module Federation runtime into the runtime chunk
4. A new hook-based plugin system for extensibility

The table below shows bundle size optimizations in a demo project using the new Module Federation plugin:

More details about this change can be found here,

#Installation size optimization

Since v1.4, we have delivered several key optimizations to reduce Rspack's installation size, decreasing the size from 63.7MB in Rspack 1.4.0 to 49.9MB in Rspack 1.5.0.

Some of the most impactful optimizations include:

• 5 MB reduction through compiler parameter adjustments
• 3 MB reduction by optimizing upstream dependencies (wasmer, SWC)
• 2 MB reduction via feature flag optimization
• 2 MB reduction through browserslist-rs data structure improvements

To further optimize installation size, we have integrated automated size checks into our daily workflow to continuously monitor changes in this metric.

#Seal phase performance optimization

In terms of build performance, Rspack 1.5 delivers major optimizations to the Seal phase (the stage responsible for code generation and optimization). By improving data structures, increasing parallelism, and introducing hot code caching, Rspack significantly improves build efficiency for large projects. Thanks to parallelization, the performance gains are even more pronounced on multi-core machines.

For example, in a large-scale application at ByteDance containing approximately 40,000 modules, the overall Seal phase time was reduced by around 50%, with substantial improvements observed across all major sub-stages:

#Misc

#Drop support for Node.js 16

Since Node.js 16 reached its end of life on September 11, 2023, and many community packages (such as webpack-dev-server, css-loader, sass-loader, etc.) have dropped support for Node.js 16, Rspack 1.5 drops support for Node.js 16 to reduce maintenance costs.

Node.js version requirements for each package:

For projects still running on Node.js 16, please follow these steps to upgrade:

1. Upgrade Node.js version: We recommend upgrading to Node.js 18.12.0 or later (Node.js 22 LTS is recommended).
2. Update CI/CD configuration: Ensure your continuous integration setup is updated to use a compatible Node.js version.

#Resolver JavaScript API

To make it easier for our users to leverage Rspack's module resolution capabilities, we have integrated rspack-resolver into the Rspack JavaScript API. It provides module resolution functionality similar to enhanced-resolve.

For usage details, please refer to the Resolver API documentation.

#Stabilization of lazy compilation

After extensive validation, the experiments.lazyCompilation option has been promoted from an experimental feature to a stable feature, and is now available at the top level of the Rspack configuration:

export default {
- experiments: {
-   lazyCompilation: true,
- },
+ lazyCompilation: true,
};

The previous experiments.lazyCompilation option will continue to work, but will emit a deprecation warning.

#Deprecated options

The Rspack experiments.topLevelAwait option was used to control support for top-level await, and it has always been enabled by default. After careful observation, we found no real-world scenarios where disabling top-level await was necessary.

As a result, this option has been deprecated and is planned for removal in Rspack 2.0, at that point top-level await support can no longer be disabled.

#Rstack progress

Rstack is a unified JavaScript toolchain centered on Rspack, with high performance and consistent architecture.

#Rslint released

We are excited to announce the release of Rslint!

Rslint is a next-generation, TypeScript-first linter, written in Go and powered by the type-checking capabilities of typescript-go.

It originates from tsgolint, created by @auvred, and has since been extended and optimized to deliver a more powerful linting experience.

Key features of Rslint include:

• ESLint-style configuration and directives: almost seamless adoption
• IDE support: VS Code extension available, with support for Cursor, Trae, and more
• Auto-fix: resolve issues instantly with rslint --fix
• Rule support: 50+ @typescript-eslint rules already implemented
• Test validation: runs the original typescript-eslint test suite to ensure rule correctness

Rslint is still in its early stage of development, and we are actively working on expanding its feature set and rule support.

We encourage you to try it out and provide feedback to help us improve Rslint together!

#Rsbuild 1.5

Providing an out-of-the-box experience has always been a core design principle of Rsbuild. In Rsbuild 1.5, we have enabled several of Rspack's latest features by default, delivering improved build performance, including:

• Enabled lazyCompilation to compile dynamically imported modules on demand, improving development server startup speed.
• Enabled lazyBarrel to optimize the build performance of barrel files and reduce unnecessary module resolution.
• Enabled inlineEnum to inline TypeScript enums, reducing the bundle size after compilation.
• Enabled typeReexportsPresence to correctly detect TypeScript type re-exports, improving type handling accuracy.

Once you upgrade to the latest version of Rsbuild, these features are enabled by default with no additional configuration required.

Rsbuild 1.5 also introduces the new output.module option, which allows generating build outputs in the ES modules format.

Currently, this option provides ESM format support for Node.js bundles. We plan to extend support to web applications in future releases.

export default {
  output: {
    target: 'node',
    module: true,
  },
};

#Rslib 0.12

In Rslib 0.12, we have integrated the Rstest testing framework into the project template. If needed, you can use Rstest to test your library projects, enabling development and testing through a unified Rstack toolchain.

In addition, we are actively designing and developing a new ESM output generation strategy, aiming to deliver ESM output quality comparable to tools like esbuild and Rollup, while keeping webpack-compatible interop behavior to ensure correctness. See interop tests for details.

#Rspress 2.0 beta

Rspress 2.0 is now in beta, with development nearing completion. We plan to release the stable version within the next two months.

The latest beta introduces a Markdown text copy component, making it easier for users to provide documentation content to large language models for analysis and processing. You can try out this feature on various Rstack documentation sites:

This feature is powered by the @rspress/plugin-llms plugin, which automatically generates files compliant with the llms.txt standard. For usage details, please refer to the @rspress/plugin-llms documentation.

#Rsdoctor 1.2

Rsdoctor 1.2 introduces several significant updates, including precise analysis of concatenated modules and an all-new Treemap visualization. These enhancements improve both the accuracy of build artifact analysis and the visualization experience, helping you better understand and optimize your project bundles.

Read more in the Rsdoctor 1.2 release blog.

#Rstest 0.2

After two months of continuous iteration and over 10 rounds of optimization, Rstest 0.2 delivers substantial improvements in both functionality and stability. This release introduces the following key enhancements:

• Mock API: Rstest now includes a comprehensive mock API, enabling developers to replace actual module implementations in test environments, with full support for mocking ES modules.
• Enhanced Watch Mode: Watch mode now supports incremental re-runs. When a test file or its dependencies change, Rstest intelligently re-executes only the affected tests, significantly improving testing efficiency.
• CLI Shortcuts: Watch mode also introduces keyboard shortcuts, allowing developers to perform common actions more quickly and seamlessly.

June 26, 2025

#Announcing Rspack 1.4

Rspack 1.4 has been released!

Notable changes:

• New features
  • Running in the browser
  • Faster SWC
  • Smaller bundles
  • Incremental build by default
  • New CssChunkingPlugin
  • Enhanced lazy compilation
  • Custom input file system
  • Performance analysis tool
• Rstack progress
  • Rsbuild 1.4
  • Rslib 0.10
  • Rspress 2.0 beta
  • Rsdoctor MCP
  • Rstest released
• Ecosystem
  • next-rspack
  • Kmi
• Upgrade guide

#New features

#Running in the browser

Starting with Rspack 1.4, we have added Wasm target support, which means Rspack can now run in browser environments, including online platforms like StackBlitz (WebContainers). This enables developers to quickly create prototypes and share code examples without having to configure local environments.

You can try out our online example directly, or learn about the StackBlitz usage guide in this documentation.

In future versions, we will continue to optimize the Wasm version's usability and bundle size.

We are also developing the @rspack/browser package, which is a browser-specific version of Rspack, allowing you to use Rspack directly in any modern browser without relying on WebContainers or specific platforms.

#Faster SWC

Over the past few months, we have been continuously collaborating with the SWC team to optimize the performance and reliability of the JavaScript toolchain. After a period of optimization, we are pleased to see that SWC's performance has improved significantly, benefiting both Rspack users and all SWC-based tools:

• JavaScript parser is 30%-35% faster
• JavaScript minifier is 10% faster

The above data is from: CodSpeed - SWC, compared against SWC 16 used by Rspack 1.3 as the baseline.

#Smaller bundles

SWC has enhanced its dead code elimination (DCE) capabilities in the current version, which combined with Rspack's powerful tree shaking functionality, enables Rspack 1.4 to generate smaller bundles.

We tested this using react-router as an example: by importing only part of its exports in the source code and then comparing the build outputs from different bundlers, we found that Rspack generates the smallest bundles.

import { BrowserRouter, Routes, Route } from 'react-router';

console.log(BrowserRouter, Routes, Route);

The output bundle sizes by different bundlers are as follows:

Data from react-router-tree-shaking-compare.

#Incremental build by default

After extensive optimization, Rspack's incremental build has become stable. In Rspack 1.4, we've enabled incremental build for all phases by default, which significantly speeds up rebuilds - HMR performance typically improves by 30%-40%, depending on the project.

Here is a performance comparison from one user after enabling incremental build:

If you need to revert to the previous behavior, you can set experiments.incremental to 'safe'. However, we recommend that most projects use the new default configuration to achieve optimal performance.

export default {
  experiments: {
    // Revert to previous behavior
    incremental: 'safe',
  },
};

#New CssChunkingPlugin

Rspack 1.4 introduces an experimental CssChunkingPlugin specifically designed for handling CSS code splitting. This plugin ensures that styles are loaded in the same order as they are imported in the source code, preventing UI issues caused by incorrect CSS loading order.

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

export default {
  plugins: [
    new rspack.experiments.CssChunkingPlugin({
      // ...options
    }),
  ],
};

Once CssChunkingPlugin is enabled, CSS code splitting will be handled entirely by this plugin, and the optimization.splitChunks configuration will no longer affect CSS modules. You can check the documentation for more details.

This plugin is inspired by Next.js's CSS Chunking feature. Thanks to the Next.js team for their innovation in this area.

#Enhanced lazy compilation

Rspack now supports enabling lazy compilation with MultiCompiler, which means that when you use multiple Rspack configurations in a single build, you can independently configure the lazyCompilation options for each compiler instance.

export default [
  {
    target: 'web',
    experiments: {
      // enable lazy compilation for client
      lazyCompilation: true,
    },
  },
  {
    target: 'node',
    experiments: {
      // disable lazy compilation for server
      lazyCompilation: false,
    },
  },
];

#Custom input file system

Rspack now allows you to customize compiler.inputFileSystem (the compiler's input file system). This feature can be enabled by configuring experiments.useInputFileSystem. Typical use cases include:

• Using memfs instead of the default input file system in browsers.
• Working with the webpack-virtual-modules plugin to support virtual modules.

import VirtualModulesPlugin from 'webpack-virtual-modules';

export default {
  entry: './virtualEntry.js',
  plugins: [
    new VirtualModulesPlugin({
      'virtualEntry.js': `console.log('virtual entry')`,
    }),
  ],
  experiments: {
    useInputFileSystem: [/virtualEntry\.js$/],
  },
};

Since the custom inputFileSystem is implemented in JavaScript, it may lead to performance degradation. To mitigate this issue, useInputFileSystem allows you to pass an array of regular expressions to filter which files need to be read from the custom inputFileSystem, which avoids performance overhead caused by replacing the native file system.

In the future, we also plan to add built-in virtual module support in Rspack to provide better performance and user experience.

For detailed usage, see the documentation.

#Performance analysis tool

Rspack 1.4 introduces more precise tracing capabilities, which can be used for performance analysis based on perfetto to quickly identify build performance bottlenecks.

You can enable tracing through the RSPACK_PROFILE environment variable:

RSPACK_PROFILE=OVERVIEW rspack build

The generated rspack.pftrace file can be visualized and analyzed at ui.perfetto.dev:

For more detailed usage, see the Tracing documentation.

#Dependency upgrades

In Rspack 1.4, we have upgraded several major dependencies, including:

• Rspack now uses Zod v4 for configuration validation.
• create-rspack now provides Biome v2 as an optional linter and formatter.

#Rstack progress

Rstack is a unified JavaScript toolchain centered on Rspack, with high performance and consistent architecture.

#Rsbuild 1.4

Rsbuild 1.4 has been released alongside Rspack 1.4, with notable features including:

#Chrome DevTools integration

We've introduced a new rsbuild-plugin-devtools-json plugin, which enables seamless integration with Chrome DevTools' new Automatic Workspace Folders feature. This means you can directly edit and debug your source code in DevTools and save changes to your local file system.

#Improved query parameters

Rsbuild now has built-in support for .js?raw query parameters, allowing you to import the raw content of JavaScript, TypeScript, and JSX files as text. This is very useful in scenarios where you need to process code as strings (such as displaying code examples).

import rawJs from './script1.js?raw';
import rawTs from './script2.ts?raw';
import rawJsx from './script3.jsx?raw';

console.log(rawJs); // Raw content of JS file
console.log(rawTs); // Raw content of TS file
console.log(rawJsx); // Raw content of JSX file

#Improved browser compatibility

When you import JS files from other packages in a monorepo, Rsbuild now uses SWC to compile them by default, which helps avoid browser compatibility issues introduced by external dependencies.

As shown in the diagram below, suppose the app's build target is ES2016 and utils' build target is ES2021. When app/src/index.js imports utils/dist/index.js, SWC will now downgrade it to ES2016.

#Rslib 0.10

Rslib 0.10 has been released, with notable features including:

#ESM output optimization

Rslib now generates cleaner, more concise, and smaller ESM output by default.

#Building Vue UI libraries

By integrating the rsbuild-plugin-unplugin-vue plugin, you can use Rslib to generate bundleless builds for Vue UI libraries.

import { defineConfig } from '@rslib/core';
import { pluginUnpluginVue } from 'rsbuild-plugin-unplugin-vue';

export default defineConfig({
  plugins: [pluginUnpluginVue()],
  lib: [
    {
      format: 'esm',
      bundle: false,
      output: {
        target: 'web',
      },
    },
  ],
});

#Output IIFE format

Rslib now supports generating IIFE format output, wrapping the code in a function expression.

See the blog for more information about Rslib.

#Rspress 2.0 beta

We are actively developing Rspress 2.0 and have released multiple beta versions. Currently, we have completed most of the code refactoring work and have integrated Shiki by default in Rspress 2.0 to provide more powerful code highlighting features.

Additionally, we are developing a brand new theme, with the preview shown below:

#Rsdoctor MCP

Rsdoctor has introduced @rsdoctor/mcp-server, which combines LLMs to help you better analyze build data. It can access Rsdoctor's local build analysis data and provide intelligent analysis and optimization suggestions.

Rsdoctor MCP provides bundle analysis, dependency analysis, bundle optimization suggestions, and build optimization suggestions. It can analyze bundle size composition, dependency relationships, and duplicate dependencies, while providing targeted optimization suggestions for bundle size optimization, code splitting, and build performance.

#Rstest released

Rstest is a brand-new testing framework built on Rspack that provides comprehensive, first-class support for the Rspack ecosystem. It integrates seamlessly into existing Rspack projects and offers Jest-compatible APIs.

This month, we released Rstest v0.0.3, which provides initial support for Node.js and UI component testing, and has been adopted in our repositories like Rsbuild.

Rstest is currently in its early stages. We recommend staying tuned as we continue to enhance its testing capabilities to provide a more complete solution.

#Ecosystem

#next-rspack

Since Rspack joined the Next.js ecosystem, our primary goal has been to improve the stability and test coverage of next-rspack.

In the latest version, next-rspack has been largely completed, with test coverage reaching:

• Production builds 99.4%
• Development builds 98.4%

Moving forward, we plan to continue pushing test coverage to 100% and further optimize the performance of next-rspack.

#Kmi

Kmi is a framework based on Umi and Rspack. By integrating Rspack as the bundler, Kmi delivers build performance improvements several times faster than the webpack version.

For developers currently using Umi, Kmi provides a progressive migration path that allows them to enjoy the performance benefits of Rspack while maintaining project stability.

For more information, see the Kmi repository.

#Upgrade guide

#Upgrade SWC plugins

If your project uses SWC Wasm plugins (such as @swc/plugin-emotion), you need to upgrade the plugins to a version compatible with swc_core@29, otherwise it may cause build errors due to version incompatibility.

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

#Lazy compilation middleware

The lazy compilation middleware has changed its way of accessing the lazyCompilation option. Now, the middleware can automatically read the lazyCompilation option from the compiler instance, so you no longer need to manually pass in the lazyCompilation option.

import { experiments, rspack } from '@rspack/core';
import { RspackDevServer } from '@rspack/dev-server';

const compiler = rspack([
  // ...multiple configs
]);

// no longer need to pass options to the middleware
const middleware = experiments.lazyCompilationMiddleware(compiler);

const server = new RspackDevServer(
  {
    setupMiddlewares: (other) => [middleware, ...other],
  },
  compiler,
);

April 10, 2025

#Rspack joins the Next.js ecosystem

One of Rspack's primary goals is to seamlessly integrate with webpack-based projects or frameworks, providing an enhanced development experience with minimal migration costs.

In the JavaScript ecosystem, Next.js has one of the most advanced build systems, with deeply customized webpack configurations and a rich plugin ecosystem. This made it an ideal candidate for testing and proving Rspack’s compatibility and robustness. Integrating Rspack into Next.js demonstrates Rspack's applicability in complex projects and provides Next.js users with an alternative solution to improve developer experience.

#Rspack comes to Next.js

Today, we’re excited to introduce next-rspack, a community-driven plugin bringing direct Rspack support to Next.js. This integration offers a fast, webpack-compatible alternative for teams not yet ready to adopt Turbopack.

Get started today by visiting our documentation or checking out the official Next.js example.

Before landing this support, we explored integration possibilities by creating rsnext, a fork of Next.js designed to prototype a near drop-in solution. This early fork played a valuable role in validating feasibility and discovering edge cases. Also, it made us realize that while Rspack’s high compatibility with webpack gave us a head start, achieving stable integration still required significant effort and collaboration.

#Partnering with Vercel on shared foundations

The launch of next-rspack is just one aspect of our broader collaboration with Vercel. This partnership extends beyond Next.js integration, as both teams focus on improving shared foundational technologies such as SWC and Lightning CSS—widely adopted tools across the JavaScript ecosystem.

By working together to enhance these core components, we're laying a stronger foundation for better developer experience, performance, and reliability. These efforts benefit not only Rspack and Next.js, but also help uplift the broader JavaScript ecosystem. A rising tide lifts all boats.

To ensure ongoing reliability, next-rspack is now integrated into Next.js’s continuous integration pipeline, proactively catching regressions and maintaining compatibility. Although still experimental, it currently passes around 96% of integration tests, giving us the confidence to publicly release this integration. You can track the latest status with arewerspackyet and following our twitter for latest progress about next-rspack.

For teams not yet ready to adopt Turbopack, next-rspack offers a solid, fast alternative with excellent compatibility and straightforward setup.

We deeply appreciate Vercel’s collaboration and shared commitment to improving the tools that developers rely on every day. We’ll continue working together to refine this integration and support the future of modern JavaScript development.

#Performance insights

#App router users

Currently, the App Router implementation with next-rspack is slower than Turbopack, and may even be slower than webpack. This is due to some JavaScript plugins that cause heavy Rust-JavaScript communication overhead.

We have experimentally ported the theses plugins to Rust, which dramatically improved performance—almost on par with Turbopack. And we are exploring how to address the long-term maintenance challenges that come with deep integration.

#Page router users

The situation is much more promising:

• Development Mode: 2x faster than webpack
• Production Mode: 1.5x faster than webpack

Users deeply integrated into the webpack ecosystem will find migration easier.

There're some known bottlenecks which limit further performance improvement(like huge Rust-JavaScript communication overhead, slower output file tracing implementation) which can be solved in the future, with expected improvements, we foresee:

• 5x faster builds and HMR in development
• 3x faster production builds

#Frequently asked questions

#How will it remain supported?

next-rspack is already integrated into Next.js’s CI pipeline, helping us catch regressions early and keep compatibility high. Support will evolve alongside both Next.js and Rspack, with ongoing collaboration between both teams and the open source community.

#Who maintains it?

next-rspack is a community plugin, but its development and integration rely on close collaboration between the Rspack and Vercel teams to ensure continued support and progress.

#Does this have any impact on Turbopack? is Vercel adopting Rspack?

Rspack doesn't replace Turbopack. It's an alternative solution for those with extensive webpack configurations who are not ready to migrate to Turbopack.

#What are known issues?

As of now, next-rspack passes around 96% of integration tests, and progress can be monitored on arewerspackyet.

• Some edge cases and advanced features may still require workarounds or additional support. Let us know how it went in the feedback discussion, even when you don't run into problems.
• Due to the current plugin implementation, the performance of the App Router is still suboptimal and there's still plenty of room for performance improvement.
• Since Rspack is not 100% compatible with webpack's API, some of your webpack plugins may not work smoothly on Rspack. Let us know if you have compatibility problems.

#How can you help?

Try out next-rspack, report issues, contribute code or docs, and join the community discussions. Your feedback and contribution is valuable.

#Future plans

• Increase Test Coverage: We aim to raise our test coverage from the current 96% to nearly 100% in the next quarter.
• Enhance Performance: We'll explore deeper integration with Next.js through native plugins to improve build performance.
• Iterate Based on User Feedback: Continue supporting more community plugins from the Next.js ecosystem.
• Improve Integration Workflow: Establish a more robust CI/CD pipeline between Rspack and Next.js to ensure the stability and reliability of next-rspack support.
• Better RSC Support: Turbopack’s unified module graph unlocks faster and simpler RSC implementation. Rspack will deliver a similar API to bring first-class, high-performance RSC support to the ecosystem.
• Module Federation Support: We are discussing with Next.js team about improved support of Module Federation.

Through 2024, stability and artifact integrity were a primary focus for Rspack. In 2025 we are focusing more on speed opportunities and broad ecosystem.

Stay tuned—we’re just getting started.

March 28, 2025

#Announcing Rspack 1.3

Rspack 1.3 has been released!

Notable changes:

• New features
  • Circular dependency detection
  • Build HTTP imports
  • Lazy compilation improvements
  • AMD supports
• Performance improvements
  • Code splitting 25% faster
  • Bundle size optimization
  • Memory improvements
• Rstack updates
  • Rsdoctor 1.0
  • Rsbuild 1.3
  • Rslib 0.6
  • Rspress and Rstest
• Ecosystem
  • Rspeedy for Lynx
  • Re.Pack 5
  • React Router v7 support
• Upgrade guide
  • Module subtypes changed
  • Upgrade SWC plugins

#New features

#Circular dependency detection

Rspack 1.3 introduces a built-in plugin CircularDependencyRspackPlugin to detect circular dependencies between runtime modules.

This plugin is implemented in Rust and deeply integrated with Rspack's module graph, avoiding expensive data copying and serialization overhead. It detects all circular dependencies by performing a single traversal of the module graph for each entry point, rather than checking each module independently, resulting in lower performance overhead.

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

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

Special thanks to @faultyserver for contributing this plugin ❤️

#Build HTTP imports

In previous versions, you could import HTTP/HTTPS resources by using externalsPresets.web or externalsPresets.webAsync options, which simply externals the these resources and let the browser (or other platform) to fetch them at runtime.

import pMap from 'https://esm.sh/p-map';

And the new experiments.buildHttp option provides a new way to import HTTP/HTTPS resources, not fetch the resources at runtime, but download them to the local cache at build time and then bundle them into your output.

export default {
  experiments: {
    buildHttp: {
      allowedUris: ['https://esm.sh/'],
    },
  },
};

See the docs for more details.

#Lazy compilation improvements

In previous versions, when lazy compilation was enabled, Rspack would start a separate server to handle lazy compilation-related requests. This led to several issues, such as the need for two servers during development, and the lazy compilation server not being able to share proxy and CORS configurations with the default dev server.

Rspack 1.3 provides new Express-style middleware for integrating lazy compilation that addresses these issues.

• If you are using @rspack/cli or Rsbuild, you can upgrade to the new middleware by simply updating the dependency version.
• If you are using a custom development server, you will need to integrate this middleware to support lazy compilation.

Here's an example of how to use the lazy compilation middleware:

import { rspack } from '@rspack/core';
import config from './rspack.config.mjs';
import DevServer from 'webpack-dev-server';

const compiler = rspack(config);
const middleware = rspack.experiments.lazyCompilationMiddleware(
  compiler,
  config.experiments.lazyCompilation,
);

const server = new DevServer(
  {
    setupMiddlewares(other) {
      return [middleware, ...other];
    },
  },
  compiler,
);

#AMD supports

Rspack now allows you to enable AMD module support by using the amd option.

Notably, Rspack differs from webpack in that the parsing of AMD modules is disabled by default (webpack enables it by default). This feature is only for compatibility with certain legacy AMD npm dependencies. We recommend prioritizing ES Module dependencies for better Rspack optimization and to boost ES Module adoption.

Add the amd option to enable support:

export default {
  amd: {
    // ...
  },
};

Special thanks to @nilptr for contributing this plugin ❤️

#Performance improvements

#Code splitting 25% faster

In Rspack 1.2, we introduced the experiments.parallelCodeSplitting option to enable the new code splitting algorithm.

Starting from Rspack 1.3, this option is enabled by default, resulting in a 25% performance boost for code splitting.

#Bundle size optimization

Rspack 1.3 introduces full support for the output.environment option, which allows you to specify which ECMAScript features can be used in the runtime code generated by Rspack, and to generate shorter and more modern runtime code.

By default, Rspack parses the target option and automatically sets the values of the output.environment sub-options based on browserslist to determine which ECMAScript features are supported by the target environment, thus outputting the optimized code.

For example, if Rspack detects that the target environment supports arrow functions, it sets output.environment.arrowFunction to true and using arrow function syntax in the generated code.

// before
- __webpack_require__.d = function(exports, definition) {

// after
+ __webpack_require__.d = (exports, definition) => {

By utilizing modern JavaScript features supported by the target environment, Rspack can output smaller runtime code. In our performance testing on a real large-scale project, this optimization reduced the bundle size by approximately 500KB (before gzip compression).

#Memory improvements

Rspack now defaults to using mimalloc v3 on macOS. This mitigates some memory consumption issue on macOS during rebuilding. According to some community and internal projects, this would lift the RSS for rebuilding, based on the size of each project, varying from 10% to 85%.

Rspack 1.3 also implemented an internal mechanism to clean the outdated cache: maxGenerations. This controls how many compilations would cache survive if it's not being used by the compiler. Rspack sets the default to 1. This means that the cache will be purged if it's not being used in the next compilation.

#Rstack updates

#Rsdoctor 1.0

After a year of development and testing, we are proud to introduce Rsdoctor 1.0 — a build analyzer tailored for the Rspack ecosystem and fully compatible with the webpack ecosystem.

Rsdoctor is committed to being a one-stop, intelligent build analyzer that makes the build process transparent, predictable, and optimizable through visualization and smart analysis, helping development teams precisely identify bottlenecks, optimize performance, and improve engineering quality.

Rsdoctor 1.0 introduces significant enhancements:

• A completely redesigned UI that delivers more intuitive and efficient information visualization.
• Rewrote data processing logic using Rust, achieving 20%+ improvement in analysis speed.
• New module search capabilities for analyzing dependencies and module sizes.

Read the Rsdoctor 1.0 release blog for more.

#Rsbuild 1.3

Rsbuild 1.3 has been released alongside Rspack 1.3, notable features including:

• Support importing compiled CSS files as strings by using the ?inline query parameter:

import inlineCss from './style.css?inline';

console.log(inlineCss); // Output the compiled CSS file content

• Support importing raw CSS files and static assets as strings by using the ?raw query parameter:

import rawSvg from './logo.svg?raw';
import rawCss from './style.css?raw';

console.log(rawSvg); // Output the raw SVG file content
console.log(rawCss); // Output the raw CSS file content

#Rslib 0.6

Rslib 0.6 brings the following notable updates:

• Improved CJS output: Rslib's CJS output can now be statically analyzed, allowing Node.js ESM modules to use named imports to reference exports from CJS output.
• Type error optimization: When type errors occur, Rslib now prints the full context and code frame to the terminal, making it easier to fix type issues.

This release also adds support for YAML and TOML. See Rslib 0.6 for more details.

#Rspress and Rstest

We are also working on:

• Rspress 2.0: A fully upgraded static site generator with richer features and better performance.
• Rstest: A testing framework powered by Rspack. It delivers comprehensive, first-class support for the Rspack ecosystem, enabling seamless integration into existing Rspack-based projects.

More information will be released soon, stay tuned 🌟

#Ecosystem

#Rspeedy for Lynx

Lynx is a family of technologies empowering developers to use their existing web skills to create truly native UIs for both mobile and web from a single codebase. Lynx was originally developed by an engineering team of ByteDance, which continues to drive its development.

Lynx has built a modern toolchain called Rspeedy based on Rspack, Rsbuild, and Rsdoctor to enable fast builds. Lynx also features a speedy, versatile rendering engine and performance-driven dual-threaded UI programming.

Read the Introductory Blog of Lynx for more.

#Re.Pack 5

Re.Pack is a build tool for building your React Native application.

Re.Pack 5 has been released, which brings unprecedented performance improvements through Rspack, proper microfrontends support through Module Federation 2, simplified configuration and more.

Read the Re.Pack 5 release blog for more.

#React Router v7 support

rsbuild-plugin-react-router has been released, which is an Rsbuild plugin that provides seamless integration with React Router v7, supporting the following features:

• Filesystem routes
• Server-side rendering
• Experimental Module Federation support

See rsbuild-plugin-react-router repository to try it out.

#Upgrade guide

#Module types changed

The module types exported by Rspack have been refined with more accurate type definitions, which helps to align with webpack. Currently supported module subtypes include:

• NormalModule
• ContextModule
• ExternalModule
• ConcatenatedModule

You can now identify a module's specific type in two ways:

// Method 1: Instance type checking
module instanceof NormalModule;

// Method 2: Constructor signature detection
module.constructor.name === 'NormalModule';

The new type definitions may cause type errors in existing JavaScript API code, such as:

module.resource; // TypeScript Error: Property 'resource' does not exist on type 'Module'

To access the resource property, you now need to assert the module type using one of the following methods:

// Solution 1: `in` operator type guard
if ('resource' in module) {
  console.log(module.resource);
}

// Solution 2: Instance type assertion
if (module instanceof NormalModule) {
  module.resource;
}

#Upgrade SWC plugins

In Rspack 1.3, the Rust crate swc_core has been upgraded to v16. 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 mismatch.

January 21, 2025

#Announcing Rspack 1.2

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

Rspack v1.2 has been released!

Notable changes:

• New features
  • Persistent cache: An experimental feature that improves hot start performance by up to 250%.
  • Yarn PnP
• Performance improvements
  • Faster code splitting: An experimental flag that significantly improve the code splitting performance.
  • Watch scope change
  • Reduced memory usage
  • Smaller minification size
  • Faster side effects optimization
• Ecosystem
  • Angular support
  • Rsbuild v1.2

#New features

#Persistent cache

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

export default {
  cache: true,
  experiments: {
    cache: {
      type: 'persistent',
    },
  },
};

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

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 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.

export default {
  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.

export default {
  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:

export default {
  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 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 Angular Rspack for more information.

#Rsbuild v1.2

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

• Customize manifest file generation through output.manifest.generate.
• Specify files to retain in the dist directory using cleanDistPath.keep.
• @rsbuild/plugin-assets-retry now generates smaller runtime code.

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 mismatch.

#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:

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

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

November 7, 2024

#Announcing Rspack 1.1

Posted by @LingyuCoder, @ahabhgk, @GiveMe-A-Name, @9aoy, @chenjiahan

Rspack v1.1 and Rsbuild v1.1 are out!

Notable changes:

• Performance improvements
  • Better scheduling strategy: Make Rspack 10% faster than v1.0.
  • New incremental rebuild: Experimental feature that makes HMR up to 38% faster.
• New features
  • Improved HTML Plugin: Refactored the built-in HTML plugin with new features.
  • Improved JSDoc: Added JSDoc for all configuration options.
• Ecosystem
  • Docusaurus Faster: Use Rspack as the bundler for Docusaurus sites.
  • Nuxt Rspack Builder: Experimental Rspack builder for Nuxt.
• Rsbuild v1.1: CLI shortcuts and new configurations.

#Performance improvements

#Better scheduling strategy

According to our benchmarks, Rspack v1.1 is 10% faster than v1.0.

A major optimization is that Rspack uses a better scheduling strategy inspired by Using Rustlang’s Async Tokio Runtime for CPU-Bound Tasks and SWC optimization for better concurrency support, which allows better scheduling of async tasks.

#New incremental rebuild

In the early versions of Rspack 0.x, we implemented experiments.incrementalRebuild. As this feature gradually stabilized, we removed the experiments configuration and enabled it by default.

However, this feature only enabled incrementality for the make and emitAssets stages of the rebuild. For many projects, the loader in the make stage takes a lot of time. At that time, this feature had a relatively obvious performance improvement in rebuild for these projects. But there are still some projects that take a lot of time in stages other than make. Therefore, we optimized and expanded this feature and gradually introduced this feature into other stages, such as buildChunkGraph, providedExports, moduleCodegen, etc.

In Rspack v1.1, we introduced experiments.incremental as the successor and superset of experiments.incrementalRebuild, aiming to bring further rebuild performance improvement and faster HMR to developers.

In a case of 10000 React components, the HMR becomes 38% faster:

In Rspack v1.1 you can enable this feature in development mode by:

const isDev = process.env.NODE_ENV === 'development';

export default {
  mode: isDev ? 'development' : 'production',
  experiments: {
    incremental: isDev,
  },
};

See experiments.incremental for more details.

This is still an experimental feature and we need more work to stabilize it. If you are interested, give it a try and send bug reports and feedback to #8106.

#New features

#Improved HTML plugin

In earlier versions of Rspack, the built-in HtmlRspackPlugin was implemented. However, its capabilities were severely lacking. It lacked some configuration options and did not support hooks, which made those plugins implemented based on the hooks of HtmlWebpackPlugin incompatible with Rspack.

Therefore, we refactored HtmlRspackPlugin. While supporting most of the configuration options of HtmlWebpackPlugin, we also completed the alignment of hooks. Now you can get these hooks through HtmlRspackPlugin.getCompilationHooks and use them to modify the content of the HTML assets like below:

const DeferPlugin = {
  apply(compiler) {
    compiler.hooks.compilation.tap('DeferPlugin', (compilation) => {
      const hooks = HtmlRspackPlugin.getCompilationHooks(compilation);
      hooks.alterAssetTags.tapPromise('DeferPlugin', async (data) => {
        // Add `defer` attribute to all script tags
        for (const tag of data.assetTags.scripts) {
          if (tag.tagName === 'script') {
            tag.attributes.defer = true;
          }
        }
      });
    });
  },
};

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

See HtmlRspackPlugin for more details.

#Improved JSDoc

Rspack uses zod to validate user configurations and infer all configuration types. However, the inferred types lack JSDoc comments and the generated types are quite complex and hard to understand.

To fix this, we recently refactored the configuration types and added JSDoc comments for all of them to improve readability.

We're still looking to improve the JSDoc. If you're interested, feel free to submit pull requests. ❤️

#Ecosystem

#Docusaurus Faster

Docusaurus v3.6 brings the Docusaurus Faster options that allow users to use Rspack as the bundler for Docusaurus sites.

The Docusaurus Faster project's goal is to reduce the build times and memory consumption of Docusaurus. Docusaurus team have worked on multiple optimizations and modernized their infrastructure to use faster Rust-based tools like Rspack and SWC.

Benchmarks on community site show that the production site can build 2 to 4 times faster.

#Nuxt Rspack builder

Nuxt v3.14 brings a new first-class Nuxt builder for Rspack.

It's still experimental and Nuxt team refactored the internal Nuxt virtual file system to use unplugin to make this possible.

You can try nuxt-rspack-starter to get started, or install @nuxt/rspack-builder and set builder: 'rspack' in the Nuxt config file.

#Rsbuild v1.1

Rsbuild v1.1 upgraded to Rspack v1.1 and introduced several new features.

#CLI shortcuts

Rsbuild now supports enabling CLI shortcuts through the dev.cliShortcuts config. If you are using Rsbuild CLI, it is enabled by default.

The CLI shortcut allows you to clear the console, open the browser, restart the server, or customize any shortcut you want.

#View static assets

Rsbuild dev server now provides a report page at /rsbuild-dev-server that allows you to view all static assets generated during the current build.

#New configurations

Rsbuild 1.1 introduced some new configurations:

• server.base: Set the base path of the server.
• source.assetsInclude: Set the additional files that should be treated as static assets.
• output.filename.assets: Set the name of other static assets.
• output.distPath.assets: Set the output directory of other static assets.

#Upgrade guide

#Upgrade SWC plugins

In Rspack v1.1, the Rust crate swc_core has been upgraded to 5.0.1. 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 SWC documentation.

#Hash function

Rspack's output.hashFunction now defaults to the faster xxhash64, and the output.hashDigestLength now defaults to 16 (prev 20). This change will bring a significant performance improvement for large projects.

If you prefer the previous hash function, you can set:

export default {
  output: {
    hashFunction: 'md5',
    hashDigestLength: 20,
  },
};

Related PR: #8249.

June 29, 2024

#Announcing Rspack 1.0 alpha

Rspack 1.0 alpha is now available on npm!

Before releasing Rspack 1.0 stable version, we will test for 1~2 months to improve the API stability and reliability of v1.0 and to verify its impact on downstream projects.

Rspack 1.0 stable version is expected to be released this August. This is a significant milestone as it means that Rspack has implemented the major features and APIs of webpack. This will allow thousands of webpack projects to make a smooth transition while achieving significant improvements in build performance.

#Outputs optimization

Rspack 1.0 enables the optimization.concatenateModules by default during production builds. This option enables module concatenation optimization, also known as scope hoisting.

export default {
  optimization: {
    // Now enabled by default in production
    concatenateModules: mode === 'production',
  },
};

The primary purpose of module concatenation is to merge multiple modules into a single function, thereby reducing the overhead associated with parsing and executing JavaScript code in the browser. By merging modules, redundant code such as import and export statements between modules can be reduced, resulting in smaller bundle sizes.

With module concatenation enabled, the output size of Rspack can be reduced by about 4% to 10% (before Gzip).

Currently, Rspack has implemented most of the optimization strategies aligned with webpack. In future versions, Rspack will explore and make improvements based on webpack to provide deeper optimizations and smaller output sizes.

#Builtin Lightning CSS

Rspack 1.0 has built-in integration with Lightning CSS. Lightning CSS is an extremely fast CSS parser, transformer, bundler, and minifier written in Rust.

The new version of Rspack has implemented the CSS minimizer plugin based on Lightning CSS, and it is now the default CSS minimizer of Rspack. Compared to the previously used SWC CSS minimizer plugin, it applies more optimizations to make the CSS output smaller.

export default {
  optimization: {
    minimizer: [
      // The default CSS minimizer changed:
-     new rspack.SwcCssMinimizerRspackPlugin()
+     new rspack.LightningCssMinimizerRspackPlugin()
    ],
  },
};

You can switch back to SwcCssMinimizerRspackPlugin by following configuration.

export default {
  optimization: {
    minimizer: [
      new rspack.SwcJsMinimizerRspackPlugin(),
      new rspack.SwcCssMinimizerRspackPlugin(),
    ],
  },
};

For example, Rspack already has tree shaking for CSS Modules, but it only removes unused CSS Modules classnames referenced by JS files. With the unusedSymbols option of Lightning CSS, Rspack can now eliminate unused declarations in CSS Modules files, including IDs, keyframes, CSS variables or other CSS identifiers.

We believe that Lightning CSS will become the shared foundation for the next generation build tools, and Rspack will support more CSS compilation features based on Lightning CSS.. Thanks to @devongovett for creating such an excellent tool.

#Lean core

To ensure the long term stability of Rspack v1, we have removed some non-core features that were built into the Rspack core. This allows the core to be lean and focused on providing common bundler features.

In v0.x, Rspack core has built-in SWC plugins to support Emotion, Styled Components, and Relay. This is because in the early days Rspack did not support the use of SWC Wasm plugins and could only integrate them into the core.

Currently, Rspack supports the use of SWC plugins via experimental.plugins in builtin:swc-loader. So we have removed the built-in plugins from the Rspack core, including:

• @swc/plugin-emotion
• @swc/plugin-relay
• @swc/plugin-styled-components

Take @swc/plugin-styled-components as an example. In v1.0, you can use it as follows.

• Installation:

npm i @swc/plugin-styled-components -D

• Configuration:

export default {
  module: {
    rules: [
      {
        test: /\.jsx?$/,
        loader: "builtin:swc-loader",
        options: {
-         rspackExperiments: {
-           styledComponents: {},
-         },
          jsc: {
+           experimental: {
+             plugins: [["@swc/plugin-styled-components", {}]],
+           },
          },
        },
      },
    ],
  },
};

#Bundling CSS

Rspack 1.0 aligns with the webpack experiment.css default value, making it easier to migrate from webpack to Rspack.

In the webpack ecosystem, there are three common approaches to bundling CSS files:

1. Use css-loader and mini-css-extract-plugin to generate standalone CSS files.
2. Use css-loader and style-loader to inject CSS through <style> tags.
3. Use experiment.css, an experimental feature introduced in webpack 5 that provides native CSS support.

In version 0.x, Rspack enabled experiment.css by default, which would conflict with css-loader. Users had to manually disable experiment.css to use css-loader.

Starting with Rspack 1.0, the default value of experiment.css changes to false, in line with webpack, allowing users to use any of the above approaches.

You can add the following configuration to continue using experiment.css:

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

#How to upgrade

To install the alpha version of Rspack and Rspack CLI:

# npm
npm add -D --save-exact @rspack/core@alpha @rspack/cli@alpha

# yarn
yarn add -D --save-exact @rspack/core@alpha @rspack/cli@alpha

# pnpm
pnpm add -D --save-exact @rspack/core@alpha @rspack/cli@alpha

During the Rspack alpha testing, new versions will still introduce some breaking changes, which we will highlight in the changelog. Please read the changelog to understand the differences before upgrading.

For Rsbuild users, please wait for the release of Rsbuild 1.0 alpha version (expected in 1-2 weeks).

#Breaking changes

#resolve.tsConfigPath

resolve.tsConfigPath config has been removed, please use resolve.tsConfig instead.

export default {
  resolve: {
-   tsConfigPath: path.resolve(__dirname, './tsconfig.json'),
+   tsConfig: path.resolve(__dirname, './tsconfig.json'),
  },
};

#rspackExperiments.styledComponents

The rspackExperiments.styledComponents option of builtin:swc-loader has been removed, please use @swc/plugin-styled-components instead.

export default {
  module: {
    rules: [
      {
        test: /\.jsx$/,
        loader: "builtin:swc-loader",
        options: {
-         rspackExperiments: {
-           styledComponents: true,
-         },
          jsc: {
+           experimental: {
+             plugins: [["@swc/plugin-styled-components", {}]],
+           },
          },
        },
      },
    ],
  },
};

#rspackExperiments.emotion

The rspackExperiments.emotion option of builtin:swc-loader has been removed, please use @swc/plugin-emotion instead.

export default {
  module: {
    rules: [
      {
        test: /\.jsx$/,
        loader: "builtin:swc-loader",
        options: {
-         rspackExperiments: {
-           emotion: true,
-         },
          jsc: {
+           experimental: {
+             plugins: [["@swc/plugin-emotion", {}]],
+           },
          },
        },
      },
    ],
  },
};

#rspackExperiments.relay

The rspackExperiments.relay option of builtin:swc-loader has been removed, please use @swc/plugin-relay instead.

export default {
  module: {
    rules: [
      {
        test: /\.jsx$/,
        loader: "builtin:swc-loader",
        options: {
-         rspackExperiments: {
-           relay: true,
-         },
          jsc: {
+           experimental: {
+             plugins: [["@swc/plugin-relay", {}]],
+           },
          },
        },
      },
    ],
  },
};

#Others

Other breaking changes:

• optimization.chunkIds defaults to 'natural' when mode === 'none', see #6956.
• optimization.moduleIds defaults to 'natural' when mode === 'none', see #6956.
• Rust crate swc_core has been upgraded to 0.95.x, please upgrade your SWC Wasm plugin, see #6887.
• Removed output.amdContainer, use output.library.amdContainer instead, see #6958.
• Removed Compilation.currentNormalModuleHooks, see #6859.
• Removed stats.modules[].profile.integration, see #6947.
• Removed some options for SwcJsMinimizerRspackPluginOptions, see #6950.

August 28, 2024

#Announcing Rspack 1.0

We are excited to introduce Rspack 1.0!

Rspack is a next-generation JavaScript bundler written in Rust, compatible with the webpack API and ecosystem, and is 10 times faster than webpack.

Eighteen months ago, we open-sourced Rspack 0.1 and received substantial feedback and contributions from the community. During this time, 170 contributors have joined in the development of Rspack, submitting over 5000 pull requests and more than 2000 issues, which have helped Rspack release over 80 versions. And Rspack's weekly downloads on npm have exceeded 100,000 🎉.

Today Rspack has reached a new milestone - 1.0. This means that Rspack is production-ready, covers most of webpack's APIs and features, and is now prepared to support more users.

#Who's using Rspack

Since Rspack was open-sourced, many enterprises and developers have used Rspack in production. The weekly npm downloads of Rspack have also exceeded 100,000.

Within ByteDance, Rspack's weekly downloads exceed 400,000, and over 1,000 web applications use Rspack, including TikTok, Douyin, Lark, Coze, and more. These projects have significantly improved build times and iteration efficiency by using Rspack. This has also helped us identify some early design issues with Rspack, prompting us to improve the architecture and strike a balance between migration cost, performance, and flexibility.

We have also seen an increasing number of enterprise users starting to use Rspack, including Microsoft, Amazon, Alibaba, Intuit, Bit.dev, Discord, and others. We are excited that Rspack can help these enterprise users to achieve progressive migration, and we look forward to further cooperation and communication with more enterprises and developers in the future.

#New features

Since the release of 0.1, Rspack has introduced numerous important features and optimizations, including:

#Better performance

As a Rust-based bundler, performance has always been a core focus for Rspack. Since the release of Rspack 0.1, we have made numerous performance improvements, optimized its performance for different scenarios, and added key features such as lazy compilation to ensure better performance in large projects.

Here is a comparison of build performance between Rspack 0.1 and Rspack 1.0 from the benchmark. Rspack has significantly improved build performance while also adding many new features:

Note that the current architecture and implementation of Rspack still have significant room for optimization. After the 1.0 release, we plan to further improve the performance by several times to better support large-scale applications.

#Better compatibility

When 0.1 was first released, Rspack had not yet implemented many webpack APIs and hooks, limiting its compatibility with webpack plugins and loaders. This required us to fork some community libraries to adapt them for Rspack, such as the early versions of @rspack/plugin-html, @rspack/plugin-minify, and @rspack/plugin-node-polyfill.

As the API support has gradually improved, Rspack has added support for more and more webpack plugins and loaders. Currently, Rspack is compatible with almost all loaders in the community. For the 50 most downloaded webpack plugins, more than 80% can be used in Rspack or have an alternative.

Building on this foundation, Rspack supports more libraries and frameworks, including React, Preact, Vue, Solid, Svelte, and NestJS. We would also like to thank the maintainers of many community plugins who have actively adapted their work for Rspack, such as unplugin and node-polyfill-webpack-plugin. Special thanks to Alexander Akait, one of the main maintainers of webpack, who helped us support many webpack loaders and plugins.

We also hope to support and create more community plugins to further enrich the webpack and Rspack ecosystem.

#Smaller bundle size

Rspack has consistently prioritized minimizing the bundle size of production builds. Since the release of 0.1, Rspack has gradually aligned its optimization capabilities with webpack, implementing features such as split chunks, tree shaking, scope hoisting and mangle exports.

When a project migrates from webpack to Rspack, these features ensure that the bundle size remains the same as webpack while improving DX. In some scenarios, the output size of Rspack has even slightly outperformed webpack.

For example, in a real-world medium-sized web application, the bundle size of Rspack 1.0 was optimized from 6600KB to 5900KB compared to Rspack 0.1, which is equivalent to webpack. In the future, Rspack will continue to explore more advanced solutions to optimize bundle size.

#Support for Module Federation 2.0

Module Federation is a micro-frontend architectural pattern widely used in the ecosystem. The Rspack team has been working with the Module Federation team to develop Module Federation 2.0. This new version provides features such as dynamic TS type hints, Chrome devtools, runtime plugins, preloading. These features make Module Federation more suitable for use as a micro-frontend architecture in large-scale web applications.

Rspack also provides backwards compatibility and support for Module Federation 1.0, making it easier for webpack projects to migrate.

#Stable API and new website

In 1.0, we have improved the stability of the configuration, JavaScript API, and plugin API. This ensures that higher-level tools and frameworks can more easily integrate with Rspack. We have also improved the guides and API documentation on the official website.

Rspack 1.0 also includes a brand new homepage. Many thanks to designer Emily Jackson and team member Zack Jackson for their efforts in making this happen.

#Why Rspack

Over the past two years, the community has seen the birth of several Rust-based bundlers, all of which have demonstrated remarkable performance. Rspack not only provides first-class performance. It also leads the community in terms of flexibility and compatibility.

The current goals of Rspack are:

• To help existing webpack projects progressively migrate to a high performance bundler, so that build performance is no longer a bottleneck for fast iterations.
• Rspack is not just suitable for environments like browser and Node.js that we are familiar with; its goal is to cover all environments where JavaScript runs. This means that Rspack can easily support Deno, Electron, cross-platform applications, MiniApps, and any other JavaScript runtime.
• We found that balancing "flexibility" and "out-of-the-box" in a single tool was a challenging task. Therefore, after open-sourcing Rspack, we developed a set of Rstack toolchains, including projects such as Rsbuild, Rspress, Rsdoctor, and Rslib, each targeting different use cases. For example, to reduce the complexity and high barriers to configuring Rspack, we provide Rsbuild for an out-of-the-box development experience.

#Rstack

Rstack is short for "Rspack Stack" and stands for the tech stack centered on Rspack. It consists of the following tools:

• Rspack: Focuses on implementing the high performance bundler, balancing performance and flexible configuration.
• Rsbuild: Focuses on building web applications, providing an out-of-the-box development experience.
• Rslib: Focuses on building libraries, providing high quality ESM and CJS outputs.
• Rspress Focuses on generating static sites and supports MDX for building documentation sites and blogs.
• Rsdoctor Focuses on build analysis, helping developers resolve build-related issues.

Together these tools make up the Rstack. We aim to provide a unified set of web development tools that deliver a top tier experience for both developers and users.

#Compatibility with webpack

Rspack 1.0 is designed to be compatible with webpack v5, which will help many projects using webpack to migrate smoothly to Rspack. While maintaining compatibility with webpack, Rspack 1.0 also embraces modern web standards and aims for ultimate build performance.

• For web standards, Rspack actively follows the evolution of modern web standards and the latest developments from TC39 and web standards. For example, Rspack already supports the use of Web Workers through new Worker(), supports importing JSON modules through Import Attributes, and supports importing CSS based on the CSS Module Scripts specification.
• For performance, we have introduced many optimizations in 1.0. For example, if a JavaScript-side hook is not used, the Rust side will not invoke communication with the JavaScript side. Also, Rspack performs lazy loading for many message objects. Even if the message object is large, if JavaScript only consumes a subset of its properties, Rspack will only transfer the consumed data, minimizing the communication overhead between Rust and JavaScript. And Rspack plans to provide even more lightweight hooks in the future to achieve more efficient communication between Rust and JavaScript.

In future major releases, Rspack will evolve based on the webpack API to better meet the needs of modern web development.

#How to use 1.0

If you are using Rspack 0.7 or an earlier version, please note that 1.0 contains some breaking changes. We have prepared detailed documentation to help you upgrade. Please refer to: Migration from Rspack 0.x.

If you have never used Rspack before, please see Quick Start to get started with Rspack. Also, feel free to give a star 🌟 to the Rspack GitHub repository.

#What's next

Rspack 1.0 marks a new beginning. Following this release, the Rspack team will focus on the following goals:

• Develop Rspack 1.x. Rspack 1.x will iterate over 12 to 18 months, bringing more new features and improvements.
• Release Rsbuild 1.0. It is based on Rspack 1.0 and supports multi-environment builds. Currently, Rsbuild has released version 1.0 RC, and the official release is expected in September.
• Release Rsdoctor 1.0. This release will improve support for Vue and provide report formats for CI/CD.
• Develop Rslib 0.x. Rslib is a library building tool based on Rsbuild. See Rslib repository for more details.
• Develop Rspress 2.0. It will be based on React 19 and will improve some of the API designs. See Rspress v2.0 planning for more details.

Here are some key features we plan to support in Rspack 1.x:

#Faster HMR

Rspack can currently meet the performance requirements for most projects, but there is still significant room for performance optimization. During development, Rspack has already achieved nearly constant level incremental builds during the make phase. However, in the seal phase, some computations can still slow down as projects scale. Rspack will incrementally optimize the computations in the seal phase to keep the HMR time at a constant level.

#Portable cache

The evolution path of Rspack's caching capabilities follows a sequential implementation of memory cache, persistent cache, and portable cache. Currently, Rspack has implemented a memory cache that provides excellent HMR performance. The next step is to implement a persistent cache based on this foundation to address long cold startup times for large projects and to functionally align with webpack.

After that, we plan to continue implementing portable cache. This means that Rspack's build cache will not only be persistent, but also portable across environments and machines. This will help teams make better use of the cache and lay the groundwork for distributed builds.

#TypeScript-based optimization

Currently, when Rspack processes TypeScript modules, it first converts them to JavaScript through a loader before further processing. This provides flexibility but also hinders further optimization of the build output. For example, developers need to use enum instead of const enum, but enum is difficult to optimize as a constant. In the future, we plan to treat TypeScript as a first-class citizen in Rspack, leveraging TypeScript's static information to provide more advanced compile-time optimization of the build output (such as type-based property renaming).

#Stable Rust API

Currently, higher-level tools can use the JS API to integrate Rspack, which provides good extensibility. However, the communication overhead between Rust and JavaScript that limits the performance of Rspack. We also provide the SWC Wasm plugin to support extensions, but its performance is still slower than native languages.To provide higher-level tools with more flexible integration options and better performance, we plan to expose Rspack's Rust API for integration.

#React Server Components support

At ByteDance, we have experimentally supported RSC (React Server Components) based on Rspack and validated it in a large web application. In the future, Rspack will provide first-class support for RSC, with more core features to make RSC easier to implement. For example, Rspack now supports the layer feature, which allows to build for multiple environments in a single run.

#Improved ESM output

ESM is the standard for JavaScript modules. We are currently improving Rspack and webpack's support for ESM output and creating a library build tool based on Rspack called Rslib. This will allow developers to make better use of ESM's static analysis and tree-shaking when building npm packages.

#Acknowledgements

The development of Rspack would not have been possible without the contributions and support of the awesome community. Special thanks to:

• The NX team for trusting in Rspack and integrating it early during its open-source phase.
• Zack Chapple and the Zephyr team for helping to promote Rspack.
• The Unplugin team for actively helping to integrate Rspack and enriching the plugin ecosystem.
• Brandon Dail for using Rspack on Discord and helping us spread the word.
• Kaffi Y for tirelessly helping users and answering Rspack-related questions on GitHub and Discord.
• All the developers participating in ByteDance's Rspack Innovator project, such as Kelvin Omereshone, Yannik Peschke, Russell Canfield, and Kyrylo who gave us early feedback and advice.
• All the companies and users who have been using Rspack since version 0.x, their valuable suggestions have helped Rspack to progress.

In the open source community, Rspack won the 2024 Breakthrough of the Year Award, which is a great encouragement for the Rspack team. We would like to thank all the developers who voted for Rspack.

Since the 0.1 release, we have established good collaborations with several community teams:

• While aligning with webpack, we worked with the webpack team to improve support for native CSS and ESM output. In the process, the Rspack team submitted over 100 commits to webpack. Special thanks to Alexander Akait for his review feedback.
• We also worked with the SWC team, contributing the Preact Refresh SWC plugin and fixing some transform and minify bugs in SWC. Thanks to kdy for his review feedback.
• Rspack has embraced the unplugin ecosystem and fully supports the unplugin API. Thanks to sxzz for his review feedback and antfu for his remarkable creativity.

We are also excited to see Rspack being used or integrated into a wider ecosystem, including Bazel, Storybook, Electron, and more.

Finally, we would like to thank all the developers who have contributed to the Rspack ecosystem ❤️:

#FAQ

#What does the 1.0 release mean?

The 1.0 release means that Rspack has implemented the core features of webpack and achieved API stability. Over the next 12 to 18 months, we will ensure the stability of the Rspack 1.x API so that developers can confidently build frameworks and tools on top of it. During the 1.x iteration, we may still find some designs require polishing in Rspack. We will address these through progressive upgrades using future flags.

#When will Rsbuild 1.0 be released?

We are currently preparing for the release of Rsbuild 1.0, which is scheduled for early September.

We have also released the Rsbuild 1.0 RC version, and there will be no further breaking changes introduced for Rsbuild. Please refer to Migrating from Rsbuild 0.x to upgrade to Rsbuild 1.0 RC.

#Does Rspack follow semantic versioning?

Rspack follows semantic versioning (semver) and will not introduce breaking changes to the public API in minor or patch releases. Note that there are some exceptions:

If your project has strict requirements for semantic versioning, you can pin Rspack to a minor version.

#Experimental features

Rspack provides some experimental features that can be used via the experiments config. In minor releases, Rspack may make changes to the APIs of these experimental features and provide detailed explanations of these changes in the release notes. So if you are using experimental features, please pay attention to the minor release notes.

#SWC related features

Rspack is built on SWC, which is currently in the pre-1.0 phase. To keep up with the fixes and improvements in SWC, we regularly update the SWC version. This may include some breaking changes in SWC or break some versions of the SWC Wasm plugins. In such cases, we will release a minor version of Rspack and add a note to the changelog. if the SWC upgrade doesn't contain any breaking changes, we may upgrade SWC in a patch or minor release.

#Types

In minor releases, the types exported by Rspack may change for the following reasons:

• TypeScript itself does not follow semver. It may introduce some breaking changes in minor releases that require Rspack to adjust its types.
• Rspack may use some features introduced in higher versions of TypeScript, which could affect projects using lower versions of TypeScript.

#Bugfix for webpack compatibility

If the webpack API was mistakenly implemented in earlier versions of Rspack, we may fix it in non-major versions to align with the webpack API's behavior.

May 28, 2024

#Announcing Rspack 0.7

Rspack v0.7 has been released!

This is the last minor release before the Rspack v1.0. After this, the Rspack team will focus on the development of v1.0 and aim to launch the Rspack v1.0 alpha version soon.

Notable changes in Rspack v0.7:

• Support for Lazy Compilation: Significantly improves the dev startup performance of large applications by compiling on demand.
• Faster CSS Build: Introducing a new css-module-lexer, which increases CSS bundling speed by 4 times.
• Breaking changes: Removed some unstable APIs to make default behaviors more consistent with webpack.

#Support for lazy compilation

Rspack v0.7 now supports lazy compilation, which is very helpful for improving the dev startup performance of multi-page applications (MPA) or large single-page applications (SPA).

#What is lazy compilation

Lazy compilation is an excellent way to improve startup performance. It compiles modules on demand rather than compiling all modules at startup. This means developers can quickly see the application running when they start the dev server and build the necessary modules in stages.

#Why need lazy compilation

Although Rspack itself has good performance, the overall build time can still be less than ideal when building applications with a large number of modules. This is because the modules in the application need to be compiled by various loaders, such as postcss-loader, sass-loader, vue-loader, etc., which introduce additional compilation overhead.

With lazy compilation enabled, Rspack will only compile the entrypoints and dynamic import modules that are requested. This can significantly reduce the number of modules that are compiled at development startup, improving startup time.

Consider the following scenario:

Your team is developing an MPA application with dozens of pages. Most of the time, you only work on a few pages and don't need to build the code for other pages. In this case, you can enable lazy compilation, allowing Rspack to compile only the modules referenced by the pages you access.

When lazy compilation is enabled, Rspack treats "entry points" and "dynamic imports" as split points. For example:

if (someCondition) {
  import('./b.js');
}

When we compile a.js, Rspack treats b.js as an empty module, as if no code had ever been written to it. As soon as we need to access b.js, Rspack fills the b.js module with its original content, as if the user had just written that piece of code.

Take the Rspack documentation site as an example, it contains several pages. With lazy compilation is enabled, only the entry points and their dependent modules will be built. This greatly improves startup speed, reducing the startup time from 2.1 seconds to 0.05 seconds.

When a developer accesses a particular page of the site, the build for that page is triggered, and this build time will still be significantly less than the full build time.

#How to use

Now, you can enable the lazy compilation feature in Rspack through the experiments.lazyCompilation configuration:

const isDev = process.env.NODE_ENV === 'development';

export default {
  experiments: {
    lazyCompilation: isDev,
  },
};

Please note that the current lazy compilation aligns with the webpack implementation, and is still in the experimental stage. In some scenarios, lazy compilation might not work as expected, or the performance improvement may be insignificant.

We will continue to improve the usability of lazy compilation in different scenarios to achieve a more stable state. If you encounter any issues while using it, feel free to provide feedback to us via GitHub Issues.

#Faster CSS builds

In v0.7, we have refactored the internal implementation of the experiments.css.

For CSS dependency analysis, we have developed css-module-lexer using Rust. This is a high performance lexer for CSS Modules that can parse CSS or CSS Modules and return their dependency metadata.

With the integration of css-module-lexer, Rspack can now support more complex CSS Modules syntax, making its behaviour align with webpack's css-loader. For example, it can support the following CSS Modules syntax:

:local(.parent):global(.child) > ul {
  color: red;
}

The CSS parsing process before and after the refactor is shown in the diagram below:

css-module-lexer has also brought significant performance improvements to Rspack's experiments.css. In performance tests, the building performance of bootstrap.css has increased by about 4x.

• Before refactoring: ~84 ms (analyzing CSS dependencies ~71 ms)
• After refactoring: ~25 ms (analyzing CSS dependencies ~11 ms)

#Breaking changes

Rspack will gradually remove all unstable APIs and configurations before version 1.0, and more configurations / APIs / default behaviors will be align with webpack.

#Deprecating unstable JavaScript APIs

Rspack early exposed some APIs that were intended for internal use only and were unstable, such as compiler.compilation and compiler.builtinPlugins. These APIs were not stable and could not be used in webpack.

In v0.7, we reorganized the currently exposed APIs and their interface definitions. If you have been using these APIs, you will need to make the necessary adjustments to align with the implementations consistent with webpack.

The following APIs are deprecated:

• compiler.builtinPlugins
• compiler.compilation
• compiler.compilationParams
• compiler.getAsset(name)
• statsError.formatted
• statsWarning.formatted
• ...

For details about the deprecated API, please refer to rspack#6448, rspack#6505.

#CSS @import rules must precede all other rules

In Rspack 0.7, we have partially refactored the internal implementation of experiments.css.

After refactoring, when @import is not at the top, you will get the following error. In this case, you need to manually adjust the @import rule to the top.

ERROR in ./src/main.css
  × Module parse failed:
  ╰─▶   × CSS parsing warning: Any '@import' rules must precede all other rules
         ╭─[4:1]
       4 │ };
       5 │
       6 │ @import 'bootstrap/dist/css/bootstrap.css';
         · ───────
       7 │
       8 │
         ╰────

  help:
        You may need an appropriate loader to handle this file type.