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

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

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:

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 {
  // [!code --]
  experiments: {
    // [!code --]
    inlineConst: true,
    // [!code --]
    inlineEnum: true,
    // [!code --]
    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: {
          // [!code --]
          rspackExperiments: {
            collectTypeScriptInfo: {
              exportedEnum: true,
              typeExports: true,
            },
            // [!code --]
          },
        },
      },
    ],
  },
};

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.

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:

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:

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.

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,
-  },
};

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.

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


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

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:

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.

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.

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.

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.

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

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.

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.

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,
);

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.

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.

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.

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:

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:

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:

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.

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 experiments.cache for more details.

Yarn PnP#

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

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

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

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.

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.

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.

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.

Remove builtins and experiments.rspackFuture.newTreeshaking#

v0.7 has removed the builtins.treeShaking (oldTreeShaking) and experiments.rspackFuture.newTreeshaking (new tree shaking switch) configurations, taking the old tree shaking functionality completely offline.

Remove resolve.browserField#

This configuration is shorthand for resolve.aliasFields = ["browser"], and since Rspack already supports resolve.aliasFields, this configuration is no longer necessary.

Remove experiments.newSplitChunks#

This configuration is used to enable the new splitChunks implementation, and since Rspack already uses the new splitChunks implementation by default, this configuration is no longer needed.

Remove snapshot#

This configuration is used to control the snapshot strategy when using cache. Under Rspack's current incremental rebuild architecture, cache no longer relies on snapshot, so this configuration is no longer needed.

Remove exportsConvention for module type css#

This configuration is used to control the naming convention of CSS module exports in experiments.css. It only has an effect on modules with the module type css/module, which have exports. For modules with the module type css, there are no exports, so this configuration is not needed.

Upgrade SWC to 0.91.x#

Upgraded the Rust crate swc_core to 0.91.x. This will affect users of the SWC Wasm plugin.

Migration guide#

Upgrade the SWC plugins#

In version v0.7, the Rust crate swc_core has been upgraded to 0.91.x. 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, please see this document of SWC.

Replace resolve.browserField with resolve.aliasFields#

If you previously configured resolve.browserField, you will need to replace it with resolve.aliasFields:

• resolve.browserField = true is replaced with resolve.aliasFields = ["browser"]
• resolve.browserField = false is replaced with resolve.aliasFields = []

Remove generator.css.exportsConvention#

If you previously configured module.generator.css.exportsConvention or generator.exportsConvention in module.rule, you only need to delete that configuration.

Rsbuild v0.7#

Rsbuild v0.7 has been released with Rspack v0.7, please read Announcing Rsbuild v0.7 to learn more.

Announcing Rspack 0.6#

Major feature updates#

Built-in support for mini-css-extract-plugin#

Now you can use rspack.CssExtractRspackPlugin as a replacement for mini-css-extract-plugin.

This is very useful in some scenarios, for example when the built-in CSS parser cannot meet your needs, there are more customized CSS Modules names, or you want to use some loaders that depend on the output of css-loader, but still want to extract the CSS into a separate file.

For more details, please see CssExtractRspackPlugin.

export default {
  plugins: [new rspack.CssExtractRspackPlugin()],
  module: {
    rules: [
      {
        test: /\.css$/i,
        use: [rspack.CssExtractRspackPlugin.loader, 'css-loader'],
      },
    ],
  },
};

There is an basic project example.

Enable new tree shaking by default#

In Rspack 0.1.0, basic tree shaking functionality was introduced. Due to the initial architecture being unstable, we employed a relatively simplistic approach to implement the basic version of tree shaking (only support unused export variables elimination). However, as rspack's capabilities improved, the architecture gradually stabilized.

The basic tree shaking functionality was insufficient to meet user needs, for example:

1. It couldn't handle circular references and couldn't provide enough optimization information for other build stages to achieve further optimization (such as mangleExports, concatenateModules, barrel exports optimization).
2. Some interoperability-related issues often occurred, such as worker-thread modules, Common Js modules, module federation, etc.

To address these issues, we decided to adopt a webpack-like approach, re-implementing the entire optimization process from the bottom up. In version 0.4.2, we introduced the experiments.rspackFuture.newTreeshaking configuration to experimentally enable the new optimization algorithm. After four months of bug fixing and optimization, the new tree shaking algorithm has become relatively stable. Therefore, we've decided to default-enable the new tree shaking algorithm in version 0.6.0.

Breaking changes#

Remove experiments.rspackFuture.disableApplyEntryLazily#

The experiments.rspackFuture.disableApplyEntryLazily option has been enabled by default since v0.5.0 and was removed in v0.6.0.

Remove compiler.build and compiler.rebuild#

compiler.build and compiler.rebuild are not part of the webpack public API and have now been removed.

Remove builtins.css and introduce CSS related module.parser and module.generator options#

Remove builtins.css, please replace it with the CSS-related module.parser and module.generator options that have been introduced.

Also, starting from v0.6.0, Rspack's experiments CSS will align with webpack's experiments CSS as a target, which means that, like webpack experiments CSS, it will no longer support browsers that do not support CSS variables in the future. Therefore, for those projects that need to use configurations not yet supported by experiments CSS, or need to support older browsers, we recommend migrating to rspack.CssExtractRspackPlugin.

In v0.6.0, we introduced three new types of module.generator and module.parser options: css/auto, css, and css/module, which will only take effect when experiments.css is enabled, checkout this example about how to use it.

In the module.parser options, module types css, css/auto, and css/module all include the namedExports property. It has replaced the builtins.css.namedExports configuration.

For the module.generator options, the css/auto and css/module module types offer the exportsOnly, exportsConvention, and localIdentName properties. The css type includes only the exportsOnly and exportsConvention properties. exportsOnly, exportsConvention, and localIdentName respectively replace builtins.css.modules.exportsOnly, builtins.css.modules.localsConvention, and builtins.css.modules.localIdentName.

In addition, there are some changes to the default values:

1. The value of exportsConvention has changed from 'asIs', 'camelCaseOnly', etc., to 'as-is', 'camel-case-only', etc., to maintain consistency with webpack experiments css.

2. With namedExports: false, it is now possible to use default exports, named exports, and namespace exports at the same time; previously, only the default export was supported:

   // Before v0.6.0, only default export was supported
   
   
   // Now, in addition to default export, it also supports:
   // Namespace exports
   
   // Named exports
   
   // Default and named exports used together
   
   

3. The default value of namedExports changed from false to true, meaning you'll have to use a namespace ) or named ) by default, which will improve future compatibility with native CSS module. And this does not mean you have to migrate all imports at once; you can disable this behavior by setting namedExports: false, and since now namedExports: false also supports named export and namespace export, you can migrate these imports progressively.

4. The default value of localIdentName has changed from '[path][name][ext]__[local]' in development mode and '[hash]' in production mode to '[uniqueName]-[id]-[local]' in both development and production modes, which will slightly improve the gzip compression size of the CSS output.

5. The default value of exportsOnly in target: 'node' has changed from false to true.

6. The default rule type for CSS has changed from css to css/auto. css/auto will automatically process CSS files with .module. or .modules. as infixes as CSS Modules, consistent with css-loader's modules.auto: true, which will simplify the writing rules for using less or sass with CSS Modules.

Upgrade SWC to 0.90.x#

Upgraded the Rust crate swc_core to 0.90.x. This will affect users of the SWC Wasm plugin.

Emit warnings when CSS order is inconsistent in multiple chunks#

When the order of CSS in multiple chunks is inconsistent, a warning will be issued. For example, if you have two entries, entryA and entryB, where entryA imports a.css and then b.css, while entryB imports b.css and then a.css. When splitChunks conditions are met, a.css and b.css will become a separate chunk. The order of a.css and b.css in this chunk cannot be guaranteed, resulting in the following warning.

WARNING in ⚠ chunk src_a_css-src_b_-5c8c53 [css-extract-rspack-plugin]
  │ Conflicting order. Following module has been added:
  │  * css ./css-loader/dist/cjs.js??ruleSet[1].rules[2].use[1]!./src/a.css
  │ despite it was not able to fulfill desired ordering with these modules:
  │  * css ./css-loader/dist/cjs.js??ruleSet[1].rules[2].use[1]!./src/b.css
  │   - couldn't fulfill desired order of chunk group(s) parent2
  │   - while fulfilling desired order of chunk group(s) parent1

If you are sure that their order inconsistency does not matter, you can ignore this error by configuring ignoreWarnings.

export default {
  ignoreWarnings: [/Conflicting order/],
};

Migration guide#

Apply rspack.CssExtractRspackPlugin#

If you have used mini-css-extract-plugin and webpack before, you can simply replace mini-css-extract-plugin by rspack.CssExtractPlugin.

+ 
- 

export default {
  plugins: [new rspack.CssExtractRspackPlugin()],
  module: {
    rules: [
      {
        test: /\.css$/i,
        use: [CssExtract.loader, 'css-loader'],
      },
    ],
  },
};

Migrate from builtins.css#

1. Use module.parser["css/auto"].namedExports to replace builtins.css.namedExports.
2. Use module.generator["css/auto"].exportsOnly to replace builtins.css.modules.exportsOnly.
3. Use module.generator["css/auto"].exportsConvention to replace builtins.css.modules.localsConvention.
4. Use module.generator["css/auto"].localIdentName to replace builtins.css.modules.localIdentName.

The above occurrences of "css/auto" are the default module type for CSS, which can be modified to "css" or "css/module" as needed.

Add the following configuration to maintain the original default behavior of builtins.css, which can be modified as needed based on the following setup:

export default {
+  module: {
+    generator: {
+      "css/auto": {
+        exportsOnly: false,
+        exportsConvention: 'as-is',
+        localIdentName: isProduction ? '[hash]' : '[path][name][ext]__[local]',
+      },
+      "css": {
+        exportsOnly: false,
+        exportsConvention: 'as-is',
+      },
+      "css/module": {
+        exportsOnly: false,
+        exportsConvention: 'as-is',
+        localIdentName: isProduction ? '[hash]' : '[path][name][ext]__[local]',
+      },
+    },
+    parser: {
+      "css/auto": {
+        namedExports: false,
+      },
+      "css": {
+        namedExports: false,
+      },
+      "css/module": {
+        namedExports: false,
+      },
+    },
+  },
}

If it is necessary to configure some modules separately, you can use the rules[].parser and rules[].generator options in module.rules.

Migrate to compiler.run#

compiler.build or compiler.rebuild have been deprecated. Please switch to compiler.run for both building and rebuilding.

Upgrade the SWC plugins#

In version 0.6.0, the Rust crate swc_core has been upgraded to 0.90.x. 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, please see this document of SWC.

Announcing Rspack 0.5#

Major feature updates#

Module Federation added to Rspack#

Checkout this blog for more details.

Breaking changes#

optimization.chunkIds is deterministic in production mode by default#

optimization.chunkIds is "deterministic" now in production mode, which aligns with webpack's default behavior.

Support rspack.HotModuleReplacementPlugin#

Support rspack.HotModuleReplacementPlugin in Rspack. If you are not using @rspack/dev-server and using a custom dev server, you need to apply HotModuleReplacementPlugin to enable HMR instead of setting devServer.hot to true, which is the same in webpack. This provides more compatibility with the plugin which uses HotModuleReplacementPlugin internally.

Remove default transformation#

Default transformation is a builtin, which internally transforms source files (such as TypeScript), into compatible sources (such as JavaScript). To make the transformation more customizable, we handed out this feature to users by using builtin:swc-loader and dropped the support of several rules[].type. These rules[].types are dropped:

• "typescript" or "ts"
• "tsx"
• "jsx"

In order to achieve old behavior, please remove rules[].type or change it to "javascript/auto" and apply your custom loader configurations.

To transform a .jsx file:

export default {
  module: {
    rules: [
      {
        test: /\.jsx$/,
        exclude: /[\\/]node_modules[\\/]/,
        loader: 'builtin:swc-loader',
        options: {
          jsc: {
            parser: {
              syntax: 'ecmascript',
              jsx: true,
            },
          },
        },
      },
    ],
  },
};

To transform a .tsx file:

export default {
  module: {
    rules: [
      {
        test: /\.tsx$/,
        exclude: /[\\/]node_modules[\\/]/,
        loader: 'builtin:swc-loader',
        options: {
          jsc: {
            parser: {
              syntax: 'typescript',
              tsx: true,
            },
          },
        },
      },
    ],
  },
};

To transform a .ts file:

export default {
  module: {
    rules: [
      {
        test: /\.ts$/,
        exclude: /[\\/]node_modules[\\/]/,
        loader: 'builtin:swc-loader',
        options: {
          jsc: {
            parser: {
              syntax: 'typescript',
            },
          },
        },
      },
    ],
  },
};

target does not affect user code anymore#

Rspack aligns target with webpack. Instead of transforming arbitrary user code, Rspack now lets loaders control the transformation of user land code. To transform user land code to which your target environment(s) needed, add env to builtin:swc-loader:

export default {
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /[\\/]node_modules[\\/]/,
        loader: "builtin:swc-loader",
        options: {
          jsc: {
            parser: {
              syntax: "ecmascript"
            }
          },
+         env: {
+           targets: "Chrome >= 48"
+         }
        }
      }
    ]
  }
}

Remove extended resolve extensions#

resolve.extensions helps us to omit certain file extensions during resolution. In previous versions, .ts, .tsx, .jsx are supported and these extensions are removed in the latest version, which aligns with webpack's behavior.

In order to get the same behavior, change resolve.extensions to this:

export default {
  resolve: {
    extensions: ['...', '.tsx', '.ts', '.jsx'], // "..." means to extend from the default extensions
  },
};

Make @swc/helpers and react-refresh as peerDependencies#

Before we remove default transformation, it's possible to use it to degrade your code to es5 by target, and insert the react refresh helper code into your react component by builtin.react.refresh, so we installed the @swc/helpers and react-refresh as the dependencies of @rspack/core, to provide the out-of-box experience. But since we removed the default transformation now, and recommend using Rsbuild for the out-of-box experience, the @swc/helpers and react-refresh no longer need to be installed by @rspack/core, and we make them as peerDependencies of @rspack/core.

If you are using externalHelpers: true with builtin:swc-loader or swc-loader, now you need to install @swc/helpers as dependencies of your project. If you are using @rspack/plugin-react-refresh, now you need to install react-refresh as devDependencies of your project.

Remove deprecated builtins options#

Some of the builtins options have been deprecated since v0.4.0.

If you are still using builtins.noEmitAssets, builtins.devFriendlySplitChunks, builtins.react, builtins.html, builtins.copy, builtins.minifyOptions, checkout migrating builtin options to builtin plugins to migrate.

And if you are still using builtins.presetEnv, builtins.decorator, builtins.pluginImport, builtins.emotion, builtins.relay, checkout the migration guide here.

Remove builtin:sass-loader#

builtin:sass-loader has been deprecated since v0.4.0. It's removed in v0.5.0. If you are still using it, migrate to sass-loader.

Remove experiments.incrementalRebuild options#

experiments.incrementalRebuild options has been deprecated since v0.4.0. It's removed in v0.5.0.

Remove builtins.devFriendlySplitChunks and experiments.newSplitChunks#

experiments.newSplitChunks and builtins.devFriendlySplitChunks has been deprecated since v0.4.0. It's removed in v0.5.0.

Remove experiments.rspackFuture.newResolver options#

experiments.rspackFuture.newResolver has been deprecated since v0.4.0. It's removed in v0.5.0.

Deprecating apply entry lazily#

Apply entry lazily is deprecating by rspackFuture: experiments.rspackFuture.disableApplyEntryLazily, which is introduced in v0.4.5, enabled by default in v0.5.0, and will be removed in v0.6.0.

When experiments.rspackFuture.disableApplyEntryLazily is false, options.entry can still make valid changes after rspack(options) is called, but with true it can't, and it's behave the same as webpack5.

This configuration has no effect on users developing applications in Rspack most of the time, but should be noted by developers of Rspack plugins or higher-level frameworks.

Migration guide#

v0.5.0 removed lots of deprecated features, except that, v0.5.0 introduced four breaking changes, and you only need to notice two of them if you are developing applications using Rspack. So v0.5.0 is easy to migrate if you already migrate to v0.4+ with no deprecate warnings, if you haven't, checkout the v0.4.0 migration guide.

Add resolve.extensions#

This is a breaking change that is most likely to affect you.

After you upgrade @rspack/core to v0.5.0, if you build failed with error: Can't resolve './src/foo.tsx', or Can't resolve './src/foo.ts', or Can't resolve './src/foo.jsx', you need to add resolve.extensions = ['...', '.tsx', '.ts', '.jsx'] in your configuration.

const configuration = {
  resolve: {
+   extensions: ['...', '.tsx', '.ts', '.jsx'],
  },
}

You only need to add the needed extensions to resolve.extensions. For example, if you are not using any .tsx or .ts files, only using .js or .jsx files, then you only need to add '.jsx' to resolve.extensions. '.js' is one of the default extensions and all default extensions (['.js', '.json', '.wasm']) are represented by '...'.

Install @swc/helpers or react-refresh#

This is a breaking change that is most likely to affect you.

After you upgrade @rspack/core to v0.5.0, if you build failed with error: Failed to resolve @swc/helpers/some-helper or Failed to resolve react-refresh/some-module, you need to install @swc/helpers or react-refresh in your project.

If you are using externalHelpers: true with builtin:swc-loader or swc-loader, now you need to install @swc/helpers as dependencies of your project.

If you are using @rspack/plugin-react-refresh, now you need to install react-refresh as devDependencies of your project.

Apply rspack.HotModuleReplacementPlugin#

If you are using @rspack/cli, or rsbuild, or other higher-level framework of Rspack to develop applications, you don't need to worry about this. This should be well handled by the higher-level framework or cli. But if you are using @rspack/core with a custom dev server (not @rspack/dev-server or webpack-dev-server), or developing a custom dev server, you need to notice this.

Before enabling HMR in Rspack is setting devServer.hot to true, but now you need to apply HotModuleReplacementPlugin by yourself in your custom dev server.

class CustomDevServer {
  enableHMR(compiler) {
-   compiler.options.devServer ??= {};
-   compiler.options.devServer.hot = true;
+   new compiler.rspack.HotModuleReplacementPlugin().apply(compiler);
  }
}

Do not change entry options after rspack(options)#

If you are using @rspack/cli, or rsbuild, or other higher-level framework of Rspack to develop applications, you don't need to worry about this. This should be well handled by the higher-level framework or cli. But if you are developing a plugin or higher-level framework, you need to notice this.

Before prepending an extra entry in Rspack is prepending it to compiler.options.entry, but now you need to apply EntryPlugin by yourself.

const { rspack } = require('@rspack/core');
const compiler = rspack(options);

function prependEntry(compiler, additionalEntry) {
-  for (const key in compiler.options.entry) {
-    compiler.options.entry[key].import = [
-      additionalEntry,
-      ...(compiler.options.entry[key].import || []),
-    ];
-  }
+  new compiler.rspack.EntryPlugin(compiler.context, additionalEntry, {
+    name: undefined, // `name: undefined` to prepend the it to every entry, or add it to a specified entry with specified entry name
+  }).apply(compiler);
}

prependEntry(compiler, 'dev-client.js');

January 09, 2024

Introducing Rspack 0.5.0#

The latest Rspack 0.5.0 introduces the highly anticipated Module Federation along with the new "v1.5" federation APIs. It marks the most substantial revamp of federation since its inception. The v1.5 offers extra capabilities for end users and framework authors, a feat unattainable with the original design.

Webpack federation gets some love!#

Federation API has been opened up for users to enrich, expand, or manage the lifecycle. While v1.5 comes with several new capabilities, it doesn't introduce breaking changes to the API regarding the original Module Federation.

v1.5 is also accessible to webpack via @module-federation/enhanced with the upper plugin ecosystem, such as the next.js federation or node.js federation plugins, already utilizing v1.5 in their canary releases.

In Rspack, Module Federation v1.5 can be used through rspack.container.ModuleFederationPlugin, and the original Module Federation can be used through rspack.container.ModuleFederationPluginV1.

Migration opportunities#

The support of Module Federation in Rspack opens up a several of creative migration options to speed up bundler tools by sharing code at runtime. Both webpack and Rspack can share code, relying on the same centralized runtime that the Module Federation Group introduced in v1.5. This ensures maintaining feature parity is manageable, and no additional forks of Module Federation are necessary to customize it.

Progressive migration to Rspack can be achieved via federation. If you have webpack locked plugins or cannot perform a full cut over to rspack, via module federation you can allow Rspack and webpack to share dependencies and code, meaning more code could be built via Rspack while the webpack host does less work but still gets the same result. example: webpack Rspack interop

Speed up builds by sharing the node_modules via federation. One could tell webpack to import: false them, and Rspack could compile all the shared modules, reducing the parse overhead and amount of code the webpack part has to do, by delegating it to Rspack where similar workloads take only a few milliseconds to perform. example: Rspack Vendor Offload to webpack apps

Migrate one at a time. Since the interfaces between webpack (@module-federation/enhanced) and Rspack are shared, users can switch over any existing federation build or remote to Rspack. We recommend any remaining webpack builds using @module-federation/enhanced which leverages our new design and exports ModuleFederationPlugin. You can, however, still use the stock plugin that ships in webpack core. Rspack should slot in seamlessly with existing federated applications.

Speed comparison to webpack federation#

In a simple comparison, using a module federation example

• Apps: 5
• Webpack: 500-3000ms per build - production
• Rspack: 130-350ms per build - production

Generally, we have observed 5-10x gains in build speeds of federated applications, roughly in line with typical performance gains we see with rspack. Most builds in module federation examples. Development builds we have converted typically take less than 150ms to cold start.

Rsbuild support#

Rsbuild continues to offer a simplified approach to build configurations. It makes working with Rspack feel less like handling a webpack-based build system. Although it's compatible with module federation, Rsbuild will be utilized to offer a more streamlined experience with module federation. For instance, Rsbuild plugins for react could automatically share defaults, or Rsbuild could provide convenient presets and patterns.

We have already initiated the migration of some module federation examples to Rspack and Rsbuild. One notable example is the CRA migration, which was seamless and took minutes to switch from CRA to Rsbuild here. This guide is also beneficial for CRA users seeking an easy performance boost for aging builds: Rsbuild Migration Guide. Rsbuild has also been fantastic for migrating Vue examples off vue-cli and onto something faster, easier, and federation friendly.

The difference between federation v1 and v1.5#

Originally Federation was quite bare. RemoteEntry exposed {get, init} interface and not much else. This ended up being very limiting, but was simple. As complex uses grew and more capabilities were discovered, it became clear we needed more control beyond the initial idea of just sharing code between builds and loading it.

v1.5 introduces runtimePlugins. These can be added to compile time via runtimePlugins options. But you can also dynamically register them in javascript files at runtime too.

In Rspack:

const { rspack } = require('@rspack/core');

new rspack.container.ModuleFederationPlugin({
  name: 'app1',
  filename: 'static/js/remoteEntry.js',
  exposes: {
    './Button': './src/components/button.js',
  },
  runtimePlugins: [require.resolve('./my-custom-plugin')]
  remotes: {
    app2: 'app2@http://localhost:3002/static/js/remoteEntry.js',
  },
  shared: {
    react: { singleton: true },
    'react-dom': { singleton: true },
  },
})

And For Webpack:

const { ModuleFederationPlugin } = require('@module-federation/enhanced');

new ModuleFederationPlugin({
  name: 'app1',
  filename: 'static/js/remoteEntry.js',
  exposes: {
    './Button': './src/components/button.js',
  },
  runtimePlugins: [require.resolve('./my-custom-plugin')]
  remotes: {
    app2: 'app2@http://localhost:3002/static/js/remoteEntry.js',
  },
  shared: {
    react: { singleton: true },
    'react-dom': { singleton: true },
  },
})

Federation can also be used in a dynamic manner, without a compile-time plugin. You can read more about v1.5 runtime here

// Can load modules using only the runtime SDK without relying on build plugins
// When not using build plugins, shared dependencies cannot be automatically reused



init({
  name: 'app1',
  remotes: [
    {
      name: 'runtime_remote1',
      alias: 'app2',
      entry: 'http://localhost:3006/remoteEntry.js',
    },
  ],
  shared: {
    react: {
      version: '18.2.0',
      scope: 'default',
      lib: () => React,
      shareConfig: {
        singleton: true,
        requiredVersion: '>17',
      },
    },
    'react-dom': {
      version: '18.2.0',
      scope: 'default',
      lib: () => ReactDOM,
      shareConfig: {
        singleton: true,
        requiredVersion: '>17',
      },
    },
  },
  plugins: [customPlugin()],
});

// Load by alias
loadRemote <
  { add: (...args: Array<number>) => number } >
  'app2/util'.then(md => {
    md.add(1, 2, 3);
  });

Read more about Federation 1.5 Update: Module Federation 1.5

Announcing Rspack 0.4#

Major changes#

Drop Node.js 14 support#

Rspack no longer supports Node.js 14, Node.js 16+ is now required.

Make @rspack/core as peer dependency of @rspack/cli#

@rspack/core is now a peer dependency of @rspack/cli rather than a direct dependency. This means that you need to manually install @rspack/core with @rspack/cli now. aligning Rspack more closely with webpack. In the long term, the positioning of @rspack/cli will no longer be an out-of-the-box solution. We will align @rspack/cli with webpack-cli and may even directly support the use of @rspack/core in webpack-cli. We recommend Rsbuild as an out-of-the-box solution.

Deprecating default transformation#

experiments.rspackFuture.disableTransformByDefault is enabled by default in v0.4.0. For people that still need the legacy behavior, you may manually set this option to false.

This feature primarily addresses three categories of problems: builtins code transformation features, target, and custom rules[].type.

1. Removal of support for some builtins features:

• builtins.relay: moved to rspackExperiments.relay
• builtins.react: moved to jsc.transform.react
• builtins.emotion: moved to rspackExperiments.emotion
• builtins.pluginImport: moved to rspackExperiments.import
• builtins.decorator: moved to jsc.parser.decorators
• builtins.presetEnv: moved to jsc.env

export default {
  module: {
    rules: [
      {
        test: /\.jsx$/,
        loader: 'builtin:swc-loader',
        options: {
          jsc: {
            parser: {
              syntax: 'ecmascript',
              jsx: true,
            },
            transform: {
              react: {
                runtime: 'automatic',
              },
            },
          },
          rspackExperiments: {
            emotion: true, // The same as `builtins`
          },
        },
        type: 'javascript/auto',
      },
    ],
  },
  experiments: {
    rspackFuture: {
      disableTransformByDefault: true,
    },
  },
};

2. target will not downgrade user-side code(including node_modules)

export default {
  target: ["web", "es5"],
  module: {
    rules: [
      {
        test: /\.[cm]?js$/,
        exclude: /node_modules/,
        loader: 'builtin:swc-loader',
        options: {
          jsc: {
            parser: {
              syntax: "ecmascript"
            },
+           target: "es5" // Notice: `jsc.target` and `env` cannot be set at the same time.
          },
+        env: { //  Notice: `jsc.target` and `env` cannot be set at the same time.
+         targets: "chrome >= 48"
+        }
        }
        type: 'javascript/auto',
      },
    ],
  }
};

3. Removed non-webpack compatible rules[].type

These types have been removed:

• "typescript"
• "jsx"
• "tsx"

For JS-related types, only the following will be retained:

• "javascript/auto"
• "javascript/esm"
• "javascript/dynamic"

Refer to this for the complete migration guide.

Check out our previous discussion here.

Deprecating builtin.react.refresh#

With experiments.rspackFuture.disableTransformByDefault is enabled by default in v0.4.0, builtin.react.refresh has also been deprecated. Now we recommend using @rspack/plugin-react-refresh to enable react fast refresh.

+ 

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

export default {
  mode: isDev ? 'development' : 'production',
  module: {
    rules: [
      {
        test: /\.jsx$/,
        use: {
          loader: 'builtin:swc-loader',
          options: {
            jsc: {
              parser: {
                syntax: 'ecmascript',
                jsx: true,
              },
              transform: {
                react: {
+                  development: isDev,
+                  refresh: isDev,
                },
              },
            },
          },
        },
      },
    ],
  },
-  builtins: {
-    react: {
-      refresh: true,
-    }
-  },
  plugins: [
+    isDev && new ReactRefreshRspackPlugin()
  ],
};

Checkout here for more details.

Deprecating builtin:sass-loader#

builtin:sass-loader has now been deprecated. If you are using it, migrate to sass-loader. Rspack will remove builtin:sass-loader in v0.5.0.

Deprecating experiments.incrementalRebuild#

experiments.incrementalRebuild has now been deprecated. Rspack will remove it in v0.5.0.

Refactoring export API in @rspack/core#

Before, some APIs should not be exported accidentally exported through re-export from @rspack/core. Now with this refactor, we clean up the export APIs from @rspack/core.

This shouldn't break anything, but if you are using unintentionally exported APIs, this may break you, and you may be using Rspack in the hacky way.

If there is a real need for removed APIs from this refactor, please raise an issue in the Rspack repository.

Deprecating builtins.devFriendlySplitChunks and experiments.newSplitChunks#

In order to full migrate to Webpack's split chunks implementation, these fields are deprecated. Rspack will remove these fields in v0.5.0.

Enable newResolver by default#

New resolver is now enabled by default.

The new resolver has passed all of enhanced-resolve's test suite. It is 5 times faster than previous implementation, and 28 times faster than enhanced-resolve.

The new resolver can be configured to read tsconfig.json's compilerOptions.paths and references field and provides better support for nested path alias. See API resolve.tsConfig for details.

To opt out of the new resolver, set experiments.rspackFuture.newResolver to false.

Migration guide#

There is a migrate example demonstrating how to migrate from Rspack 0.3.14 to Rspack 0.4.0.

Choose @rspack/cli or Rsbuild?#

If your application is a CSR application, we strongly encourage you to use Rsbuild instead of configuring Rspack yourself, as Rsbuild is much easier to use compared to @rspack/cli.

Upgrade Node.js version#

Rspack no longer supports Node.js 14 as of version 0.4.0; Node.js 16+ is now required.

Install @rspack/core manually with @rspack/cli#

{
  "devDependencies": {
+    "@rspack/core": "0.4.0",
     "@rspack/cli": "0.4.0"
  }
}

Use builtin:swc-loader to support module transformation#

Rspack no longer transforms files by default as of version 0.4.0, you can still enable old transform behavior by the following setting

{
  experiments: {
    rspackFuture: {
      disableTransformByDefault: false; // set to old transform behavior
    }
  }
}

But we suggest you use builtin:swc-loader to transform files now. More details are available in Deprecating Default Transformation.

Use @rspack/plugin-react-refresh for React applications#

builtin.react.refresh does not work when we disable the default transformation, so you need to use @rspack/plugin-react-refresh to enable fast refresh. More details are available in Deprecating builtin.react.refresh.

Migrating builtin options to builtin plugins#

In v0.4.0, Rspack deprecated some of the builtin options and migrated them to builtin plugins.

Currently, Rspack's internal plugins are divided into two categories:

• Plugins compatible with Webpack, such as DefinePlugin, ProvidePlugin, etc. This part has been fully aligned with webpack.
• Rspack-specific plugins, such as SwcJsMinimizerRspackPlugin, CopyRspackPlugin, etc.

The original builtins.define can be migrated as follows:

+ 

export default {
-  builtins: {
-    define: { process.env.NODE_ENV: JSON.stringify(process.env.NODE_ENV) }
-  },
+  plugins: [
+    new rspack.DefinePlugin({ process.env.NODE_ENV: JSON.stringify(process.env.NODE_ENV) })
+  ]
}

For builtins.html, it can be directly migrated to HtmlRspackPlugin:

+ 

export default {
-  builtins: {
-    html: [{ template: "./index.html" }]
-  },
+  plugins: [
+    new rspack.HtmlRspackPlugin({ template: "./index.html" })
+  ]
}

When there are multiple configurations in builtins.html, multiple plugin instances can be created:

export default {
  plugins: [
    new rspack.HtmlRspackPlugin({ template: './index.html' }),
    new rspack.HtmlRspackPlugin({ template: './foo.html' }),
  ],
};

For builtins.copy, it can be directly migrated to CopyRspackPlugin.

For the original builtins.minifyOptions, we provide SwcJsMinimizerRspackPlugin:

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

Other builtin options can be directly referred to the rspack builtin plugins for migration, or completed according to the CLI prompts after upgrading to v0.4.0.

Announcing Rspack 0.3#

Breaking changes#

In version 0.3, Rspack aligns the default CSS handling behavior with webpack when set experiments.css = true. This involves removing many built-in CSS transformation logic, which introduces some breaking changes. If your application previously relied on these transformation logic, please pay attention to the migration steps below.

Removal of @rspack/postcss-loader and builtins.postcss#

Before Rspack fully supported postcss-loader, Rspack implemented @rspack/postcss-loader and built-in builtins.postcss to fulfill the functionality. Currently, Rspack fully supports postcss-loader, so we have decided to deprecate @rspack/postcss-loader and builtins.postcss. Users of @rspack/postcss-loader can seamlessly migrate to postcss-loader, while users that previously used Rspack's builtins.postcss for the px2rem conversion functionality can migrate to postcss-loader and postcss-plugin-px2rem. Here is the migration process:

• Before:

export default {
  builtins: {
    postcss: {
      pxtorem: {
        rootValue: 50,
      },
    },
  },
};

• After:

export default {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          {
            loader: 'postcss-loader',
            options: {
              postcssOptions: {
                plugins: [
                  [
                    'postcss-plugin-px2rem',
                    {
                      rootValue: 100,
                    },
                  ],
                ],
              },
            },
          },
        ],
      },
    ],
  },
};

Removal of built-in CSS autoprefixer functionality#

To align better with webpack's CSS handling, Rspack removes the built-in autoprefixer functionality in 0.3. You can use postcss-loader to achieve autoprefixer.

export default {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          {
            loader: 'postcss-loader',
            options: {
              postcssOptions: {
                plugins: [['autoprefixer']],
              },
            },
          },
        ],
        type: 'css',
      },
    ],
  },
};

You can refer to the examples/postcss-loader for a complete example.

Access to internal modules restricted#

Due to the current instability of the internal module API in Rspack, directly accessing the internal modules can easily lead to breaking changes. Therefore, Rspack restricts the ability to directly access internal modules and only supports accessing Rspack's API from the root module.

• Before:

 // not supported since 0.3

• After:

Major feature updates#

Web Workers support#

Rspack natively supports Web Workers, which means you can use Web Workers out of the box without using worker-loader. Here is how to use it:

new Worker(new URL('./worker.js', import.meta.url));
new Worker(new URL('./worker.js', import.meta.url), {
  name: 'my-worker',
});

For more information about web workers support, see web workers.

builtin:swc-loader support#

Although Rspack provides many SWC compilation configuration options, these configurations are global and cannot fulfill the requirement of using different SWC transformation logic for different modules. Therefore, Rspack supports builtin:swc-loader to provide more fine-grained SWC transformation configuration. Compared to the JavaScript version of swc-loader, builtin:swc-loader has better performance. You can use builtin:swc-loader as follows:

export default defineConfig({
  module: {
    rules: [
      {
        test: /\.jsx$/,
        use: {
          loader: 'builtin:swc-loader',
          options: {
            jsc: {
              parser: {
                syntax: 'ecmascript',
                jsx: true,
              },
              transform: {
                react: {
                  pragma: 'React.createElement',
                  pragmaFrag: 'React.Fragment',
                  throwIfNamespace: true,
                  development: false,
                },
              },
            },
          },
        },
        type: 'javascript/auto',
      },
    ],
  },
});

You can refer to examples/builtin-swc-loader for more examples. Currently, builtin:swc-loader still has limitations, such as not supporting Wasm plugins, etc. Rspack will continue to iterate and support more features of builtin:swc-loader in future versions.

Improved profile support#

Performance optimization is a common requirement in business support. To reduce the cost of performance optimization for businesses, we have improved the experience of Rspack Profile. You can generate profile-related files for performance optimization by using the RSPACK_PROFILE environment variable.

$ RSPACK_PROFILE=ALL rspack build

For more detailed information about Profile, see Performance Profiling.

Alignment with More APIs

• splitChunks.chunks supports regex.
• Supports splitChunk.\{cacheGroup\}.type.
• Supports splitChunk.\{cacheGroup\}.idHint.
• Supports ensureChunkConditionsPlugin.
• rules[].use supports functions.
• Supports configuration.profile.

More hook and plugin support#

Compared to version 0.2, we have implemented more plugin APIs and made compatibility improvements for more plugins in version 0.3. At the same time, we have refined the plugin API support progress of webpack, making the support progress of plugin APIs transparent. You can track the implementation progress of plugin APIs here: plugin-api-progress.

Alignment with webpack architecture#

In version 0.3, we have further optimized the alignment with the webpack architecture, migrating from the original AST-based codegen architecture to the string transformation-based architecture. This alignment work further ensures that Rspack can align with more Hook APIs of webpack during the codegen stage to be compatible with more community plugins.

Rspack ecosystem#

Starting from version 0.2, Rspack provides support for vue-loader. However, creating a complete Vue.js CLI solution based on vue-loader can be a complex task. To simplify the development of Vue.js applications using Rspack, we offer the Rsbuild, which is an out-of-the-box solution. This solution helps developers easily develop Vue.js applications using Rspack.

Announcing Rspack 0.2#

It has been almost three months since the release of Rspack 0.1. We have received so much attention and feedback from the community, and we are grateful.

In version 0.2, we have added many features, such as: realContentHash, DataURI, support for ESM format, strengthened compatibility with webpack, and optimized many details. In addition, thanks to compatibility with the webpack API, we have also further achieved compatibility with the surrounding ecosystem. Completing tests for compatibility with vue-loader versions 17 (corresponding to Vue 3) and 15 (corresponding to Vue 2). You can now try using Rspack in Vue 2/3 projects.

We look forward to you experiencing these new improvements in version 0.2, and welcome your feedback.

Main feature updates#

Loader#

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

Plugin hooks#

New hooks for plugins have been added.

Compiler hooks:

1. beforeCompile
2. afterCompile

Compilation hooks:

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

NormalModuleFactory hooks:

1. beforeResolve
2. afterResolve
3. ResolveForScheme

ContextModuleFactory hooks:

1. beforeResolve

realContentHash#

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

ESM/System format#

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

export default {
  // …
  experiments: {
    outputModule: true,
  },
  output: {
    chunkFormat: 'module',
    chunkLoading: 'import',
    library: {
      type: 'module',
    },
  },
};

New SplitChunksPlugin implementation#

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

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

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

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

DataURI support#

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

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

export default {
  module: {
    rules: [
      {
        scheme: 'data',
        type: 'asset/resource',
      },
    ],
  },
};

Breaking changes#

• Alignment of Filename Generation Logic

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

  export default {
    output: {
  -    filename: "[name][ext]",
  +    filename: "[name].js",
  
  -    chunkFilename: "async/[name][ext]",
  +    chunkFilename: "async/[name].js",
  
  -    cssFilename: "[name][ext]",
  +    cssFilename: "[name].css",
  
  -    cssChunkFilename: "async/[name][ext]",
  +    cssChunkFilename: "async/[name].css",
    }
  }
  

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

• Enabled realContentHash by default in production

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

• Modified the Extensions of Resolve

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

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

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

Webpack compatibility updates#

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

fork-ts-checker-webpack-plugin#

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

license-webpack-plugin#

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

style-loader & css-loader#

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

node-loader#

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

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

Framework ecosystem updates#

Modern.js Framework#

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

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

Modern.js Doc#

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

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

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

Vue#

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

Svelte#

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

Storybook#

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

Angular#

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

NestJS#

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

Dev guide#

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

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

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

Test infrastructures#

In order to ship with confidence, we are currently:

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

Nightly release#

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

Acknowledgements#

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

Special thanks to:

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

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

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

Announcing Rspack 0.1#

Today we are so thrilled to announce that Rspack is officially released! Rspack is a Rust-based JavaScript bundler developed by the ByteDance Web Infra team that has features including high-performance, webpack interoperability, flexible configuration etc. Rspack has solved many problems in our scenarios and improved the developer experience for JavaScript engineers. To help more people get involved in this exciting project, we decided to open source this project. You are welcomed to create a pull request or issue.

Why Rspack?#

There are a lot of giant JavaScript applications inside ByteDance. They have very complex build configurations/scripts which may cost ten minutes to half an hour. We have tried so many ways to improve the build performance, but all existing solutions in the world lead to some other issues while solving some of them. After tons of work, we understand the requirements for a bundler are:

• Dev startup performance. npm run dev is a daily script for developers that may run many times. Reducing the cost of them to one minute from ten minutes is really life-saving.
• Build performance. npm run build is common in CI/CD environments and determines the efficiency of launch. Many giant applications in ByteDance are built in 20 ~ 30 minutes. If we can reduce it to 3~5 minutes, developers will be really productive.
• Flexible configuration. Giant projects always have complex configurations and can't be standardized. Back in time, we migrated some of the projects to other build tools to improve build performance, and the hardest part is changing the configuration.
• Production optimization. We tried various solutions in the community and webpack gave the best result in production optimization like chunk-splitting, tree-shaking, etc. A better chunk strategy can help web apps get better metrics performance.

In conclusion, we decided to build our own bundler, which is Rspack.

How is Rspack doing now?#

The Rspack project started about 11 months ago. Although it's still in the early stages, it can bring 5~10 times improvement to applications' build scripts. The metrics can be better when we finish all the optimizations.

Rspack has completed the architecture of webpack loader. It means you can use all kinds of loaders in the community, such as babel-loader, less-loader, svgr etc. We are planning to support all features of loader in Rspack. By that time, you can use loaders which haven't been supported for now, such as vue-loader.

Rspack currently only supports memory cache. Persistent and portable cache will be added in the future. We are working on a build system that can make cache shareable between two devices or environments. And Rspack will help accomplish that.

Rspack is now available in all frameworks inside ByteDance, and we are trying to collaborate with all friends in the community. Just like webpack, Rspack is an infrastructure for JavaScript ecosystems, which means that frameworks and Rspack can be beneficial for each other.

Acknowledgement#

Rspack can not be shipped today without the inspiration and support of various projects in the community. We would like to show our respect to these predecessors:

• The webpack team and community for creating a great bundler and ecosystem from which we draw a lot of inspiration.
• @sokra for the great work on the webpack project.
• @ScriptedAlchemy for creating Module Federation and helping Rspack connect with the community.
• The SWC project created by @kdy1, which powers Rspack's code parsing, transformation and minification.
• The esbuild project created by @evanw, which inspired the concurrent architecture of Rspack.
• The NAPI-RS project created by @Brooooooklyn, which powers Rspack's node-binding implementation.
• The Parcel project created by @devongovett which is the pioneer of rust bundler and inspired Rspack's incremental rebuild design.
• The Vite project created by Evan You which inspired Rspack's compatibility design of webpack's ecosystem.
• The Rolldown project created by Rolldown team, which explores the possibility of making a performant bundler in Rust with Rollup-compatible API. It inspires the design principles of Rspack.
• The html-webpack-plugin project created by @jantimon, @rspack/html-plugin is a fork of html-webpack-plugin to avoid some webpack API usage not supported in Rspack.
• The Turbopack project which inspired the ast path logic of Rspack.

Future plans#

Improve basic capabilities#

Keep building Rspack will be our top priority. Compared with webpack, Rspack is still a baby, lacking complex features. Please keep sending us feedback on feature requests. We will finish them step by step.

Working with community partners#

We would love to offer some help with Rspack integration in your framework. If you are an engineer maintaining a framework who happens to be interested in giving Rspack a try, please contact us. We have also established a partnership with the webpack team. Rspack is an attempt to optimize webpack performance using Rust, and in the future, we will explore more possibilities for optimizing webpack together with the webpack team. When Rspack reaches a certain level of maturity, webpack will attempt to integrate Rspack into webpack with experiments flag.

Improve plugin capabilities#

Rspack has supported most of the loader APIs, but only a few plugin APIs. There are two reasons why we haven't supported them all. One is that some APIs are bad for performance, so we didn't explore them for developers. And the other reason is simply lack of time, so you can create a merge request to help us.

A high performance plugin system is under discussion. It may be shipped out someday. Hopefully it can help developers get shorter build time while accessing a flexible configuration.

Continuously improve performance#

Currently, Rspack is a project with performance as the core selling point, so in the future we will do a lot of things to maintain this feature, such as improving the performance observation lab and doing a good job of performance prevention; using concurrent/multi-core friendly algorithms in more scenarios; developing a caching system that can be shared across platforms; optimizing memory usage and consumption, etc.

Build a quality assurance system#

Webpack has already accumulated very rich test cases, and in the future Rspack will reuse the existing test cases of webpack to improve its code coverage. Build a better CI system, and build an Ecosystem CI system with community projects to ensure that project upgrades do not cause breaks on upstream projects, to ensure long-term project health, and to ensure long-term increase in test coverage.

Trial#

• Quick start: rspack.rs
• GitHub Repo: github.com/web-infra-dev/rspack

Check here for the latest articles and release announcements about Rspack.

Announcing Rspack 1.7#

December 31, 2025

Rspack 1.7 has been released, improving SWC Wasm plugin compatibility, importing assets as bytes, and stabilizing multiple experimental features.

Announcing Rspack 1.6#

October 30, 2025

Rspack 1.6 has been released with better ESM output, enhanced tree shaking, support for the import defer syntax, stabilized layers feature, and default barrel file optimization.

Announcing Rspack 1.5#

August 26, 2025

Rspack 1.5 has been released, introducing barrel file optimization and constant inlining optimization, also adding a built-in file system watcher, a virtual modules plugin, and a Rust extension mechanism, while dropping support for Node.js 16.

Bundler tree shaking principles and differences#

July 31, 2025

Tree shaking has become an essential part of modern front-end bundling. This article provides a brief overview of tree shaking principles across different bundlers and explores their key differences.

Announcing Rspack 1.4#

June 26, 2025

Rspack 1.4 has been released with support for running in the browser, incremental builds enabled by default, faster SWC, smaller bundles, and new features including the CssChunkingPlugin.

Rspack joins the Next.js ecosystem#

April 10, 2025

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.

Announcing Rspack 1.3#

March 28, 2025

Rspack 1.3 has been released with support for detecting circular dependencies, building HTTP imports, and referencing AMD modules. It introduces a new lazy compilation middleware, while also improving code splitting performance, output bundle size, and memory usage.

Announcing Rspack 1.2#

January 21, 2025

Rspack 1.2 has been released, introducing experimental persistent caching, a faster code splitting algorithm, and Yarn PnP support.

Build systems and bundlers#

January 7, 2025

This article will briefly introduce the content of the "Build Systems à la Carte: Theory and Practice" paper and attempt to summarize bundlers from the perspective of build systems.

RSC and Server Action bundle practice#

January 6, 2025

This article introduces the construction practices of RSC (React Server Components) and Server Action in React, including their concepts, rendering methods, bundling process in webpack, and how Turbopack bundles multiple environment modules in a module diagram.

Announcing Rspack 1.1#

November 7, 2024

Rspack and Rsbuild 1.1 has been released, significantly improve the performance of cold starts and incremental builds. It also improve the built-in HTML plugin and types of configuration options.

Announcing Rspack 1.0#

August 28, 2024

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.

Announcing Rspack 1.0 Alpha#

June 29, 2024

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.

Announcing Rspack 0.7#

May 28, 2024

Rspack 0.7 has been released, featuring support for lazy compilation, which can significantly improve the dev startup performance of large applications. It also introduces a brand-new css-module-lexer, increasing CSS bundling speed by 4 times.

Deep dive into Rspack tree shaking#

April 17, 2024

This article primarily focuses on understanding the concept of Rspack & webpack tree shaking.

Announcing Rspack 0.6#

April 10, 2024

Rspack 0.6 is out, with built-in support for mini-css-extract-plugin and new tree-shaking enabled by default.

Webpack chunk graph algorithm#

January 12, 2024

This article introduces the chunk strategy of webpack. Through this article, you can understand when a chunk will be generated in the code and how to reduce the chunk size, etc.

Announcing Rspack 0.5#

January 09, 2024

Rspack 0.5 is out, supporting Module Federation and removing the default SWC transformation.

Module Federation added to Rspack#

January 09, 2024

The latest Rspack 0.5.0 introduces the highly anticipated Module Federation, which is detailed in this article.

Webpack CSS order issue#

November 29, 2023

This article shows how the CSS order problem occurs in webpack and how to solve it.

Announcing Rspack 0.4#

November 02, 2023

Rspack 0.5 is out, removing support for some builtin features.

Deep dive into Top-level await#

October 26, 2023

In this article, we will take a closer look at aspects such as the specification, toolchain support, webpack runtime, and profiling of Top-level await.

Design trade-offs in bundler#

August 30, 2023

This article explains why we decided to develop Rspack and what trade-offs we made during the design process.

Announcing Rspack 0.3#

August 24, 2023

Rspack 0.3 is out, adding support for web workers and the builtin:swc-loader.

Announcing Rspack 0.2#

June 02, 2023

Rspack 0.2 is out, introducing many new features, such as support for realContentHash, DataURI, and the ESM format, and more.

Announcing Rspack 0.1#

March 06, 2023

Rspack has officially been released!