# Rspack > [Rsdoctor](/guide/optimization/use-rsdoctor.md) provides the`Bundle Size`module, which is mainly used to analyze the information of the outputs of Rspack, including the size of resources, duplicate --- # Source: https://rspack.dev/guide/optimization/analysis.md # Bundle analysis ## Rsdoctor's bundle analysis [Rsdoctor](/guide/optimization/use-rsdoctor.md) provides the `Bundle Size` module, which is mainly used to analyze the information of the outputs of Rspack, including the size of resources, duplicate packages, and module reference relationships: - **Bundle Overview**: Displays the total number and size of artifacts, as well as the number and size of each file type. It also shows the duplicate packages and their reference chains. - **Bundle Analysis Module**: Analyzes the size and code information of the build artifacts' resources (**Assets**) and the included **Modules**. In this module, you can view the **actual code size of modules after packaging** in the Assets, as well as the original code or **packaged code segments** and **module reference relationships**. ![](https://assets.rspack.rs/others/assets/rsdoctor/bundle-size.jpg) Click on the **"Bundle Size"** option in the navigation bar to view the Bundle analysis report. You can see more details from this page: [Bundle Size](https://rsdoctor.rs/guide/usage/bundle-size) ### Reduce duplicate dependencies Bundle size optimization is an important part in production build because it directly affects the user experience of online users. In this document, we will introduce some common bundle size optimization methods in Rspack. It is common for web projects to bundle multiple versions of third-party dependencies. Duplicate dependencies can lead to increased bundle size and slower build speed. - Detect duplicate dependencies You can use [Rsdoctor](https://rsdoctor.rs) to detect whether there are duplicate dependencies in the project. Rsdoctor will analyze during the build process, find any duplicate bundled dependencies and display them visually: ![](https://assets.rspack.rs/others/assets/rsdoctor/overall-alerts.jpg) For more details, see [Rsdoctor - Duplicate Dependency Problem](https://rsdoctor.rs/blog/topic/duplicate-pkg-problem). ## bundle-stats and statoscope You can also generate a `stats.json` file for further analysis with other bundle analysis tools like [bundle-stats](https://github.com/relative-ci/bundle-stats) or [statoscope](https://statoscope.tech/): ```sh $ rspack build --json stats.json ``` --- # Source: https://rspack.dev/blog/announcing-0-1.md _March 06, 2023_ # 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](https://webpack.js.org/) for creating a great bundler and ecosystem from which we draw a lot of inspiration. - [@sokra](https://github.com/sokra) for the great work on the [webpack](https://github.com/webpack/webpack) project. - [@ScriptedAlchemy](https://github.com/ScriptedAlchemy) for creating Module Federation and helping Rspack connect with the community. - The [SWC](https://github.com/swc-project/swc) project created by [@kdy1](https://github.com/kdy1), which powers Rspack's code parsing, transformation and minification. - The [esbuild](https://github.com/evanw/esbuild) project created by [@evanw](https://github.com/evanw), which inspired the concurrent architecture of Rspack. - The [NAPI-RS](https://github.com/napi-rs/napi-rs) project created by [@Brooooooklyn](https://github.com/Brooooooklyn), which powers Rspack's node-binding implementation. - The [Parcel](https://github.com/parcel-bundler/parcel) project created by [@devongovett](https://github.com/devongovett) which is the pioneer of rust bundler and inspired Rspack's incremental rebuild design. - The [Vite](https://github.com/vitejs/vite) project created by [Evan You](https://github.com/yyx990803) which inspired Rspack's compatibility design of webpack's ecosystem. - The [Rolldown](https://github.com/rolldown-rs/rolldown) project created by [Rolldown team](https://github.com/sponsors/rolldown-rs), 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](https://github.com/jantimon/html-webpack-plugin) project created by [@jantimon](https://github.com/jantimon), `@rspack/html-plugin` is a fork of [html-webpack-plugin](https://github.com/jantimon/html-webpack-plugin) to avoid some webpack API usage not supported in Rspack. - The [Turbopack](https://github.com/vercel/turbo) 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](/guide/start/quick-start.md) - GitHub Repo: [github.com/web-infra-dev/rspack](https://github.com/web-infra-dev/rspack) --- # Source: https://rspack.dev/blog/announcing-0-2.md _June 02, 2023_ # 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](/api/loader-api/index.md). ### Plugin hooks New hooks for plugins have been added. Compiler hooks: 1. [beforeCompile](/api/plugin-api/compiler-hooks.md#beforecompile) 2. [afterCompile](/api/plugin-api/compiler-hooks.md#aftercompile) Compilation hooks: 1. [optimizeModules](/api/plugin-api/compilation-hooks.md#optimizemodules) 2. [optimizeChunkModule](/api/plugin-api/compilation-hooks.md#optimizechunkmodules) 3. [finishModules](/api/plugin-api/compilation-hooks.md#finishmodules) 4. [chunkAsset](/api/plugin-api/compilation-hooks.md#chunkasset) NormalModuleFactory hooks: 1. [beforeResolve](/api/plugin-api/normal-module-factory-hooks.md#beforeresolve) 2. [afterResolve](/api/plugin-api/normal-module-factory-hooks.md#afterresolve) 3. [ResolveForScheme](/api/plugin-api/normal-module-factory-hooks.md#resolveforscheme) ContextModuleFactory hooks: 1. [beforeResolve](/api/plugin-api/context-module-factory-hooks.md#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: ```js title="rspack.config.mjs" 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: ```js import x from 'data:text/javascript,export default 42'; ``` In addition, we have supported `mimetype` and `scheme` as two types of module rule conditions. For example, you can make resources with `scheme` as `'data'` no longer treated as inline processing, but as separate resource files through the following method: ```js title="rspack.config.mjs" 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: ```diff title="rspack.config.mjs" 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](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](https://github.com/web-infra-dev/rspack/pull/3338) - Modified the Extensions of Resolve Details: [https://github.com/web-infra-dev/rspack/pull/3242](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](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](https://github.com/TypeStrong/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](https://github.com/xz64/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](https://github.com/webpack/style-loader) & [css-loader](https://github.com/webpack/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](https://github.com/webpack-contrib/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](https://github.com/rstackjs/rstack-examples/tree/main/rspack/loader-compat) and [plugin-compat](https://github.com/rstackjs/rstack-examples/tree/main/rspack/plugin). 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](https://modernjs.dev/en/) 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](https://modernjs.dev/doc-tools/) - 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](https://github.com/web-infra-dev/modern.js) 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](/guide/tech/vue.md). ### Svelte Thanks to Rspack's excellent support for the Loader API and the excellent design of [svelte-loader](https://github.com/sveltejs/svelte-loader), Rspack has fully adapted [svelte-loader](https://github.com/sveltejs/svelte-loader). Therefore, you can directly use [svelte-loader](https://github.com/sveltejs/svelte-loader) in Rspack for svelte application development. You can refer to [example-svelte](https://github.com/rstackjs/rstack-examples/tree/main/rspack/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](/guide/migration/storybook.md) 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](https://valor-software.com/) 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](https://rosa.be/), [Nx](https://nx.dev/), and [Valor](https://valor-software.com/), Rspack has completed the compilation support for [NestJS](https://nestjs.com/). 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](https://github.com/TheLarkInn) and [@alexander-akait](https://github.com/alexander-akait), for answering and resolving many of Rspack team's questions about Webpack. - [@zackarychapple](https://github.com/zackarychapple), [@valorkin](https://github.com/valorkin), [@edusperoni](https://github.com/edusperoni), and [@Coly101](https://github.com/Coly010) for assisting the Rspack team with basic support for Angular and [@zackarychapple](https://github.com/zackarychapple) for reviewing this release blog. - [@suxin2017](https://github.com/suxin2017), for supporting System.js format and optional-dependency functionality in Rspack, as well as contributing a lot in terms of Windows compatibility. - [@faga295](https://github.com/faga295), for supporting the decompression code comment feature and rspack preview feature in Rspack. - [@lippzhang](https://github.com/lippzhang), for making numerous contributions in aligning Rspack's behavior with Webpack. - [@HerringtonDarkholme](https://github.com/HerringtonDarkholme), for allowing Rspack to use rspack.config.ts as a configuration file. - [@dhruvkelawala](https://github.com/dhruvkelawala), for implementing the builtins.provide feature in Rspack. - [@magic-akari](https://github.com/magic-akari), for supporting the `new URL("./foo", import.meta.url)` syntax in Rspack. - [@tuchg](https://github.com/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! --- # Source: https://rspack.dev/blog/announcing-0-3.md _August 24, 2023_ # 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: ```js title="rspack.config.mjs" export default { builtins: { postcss: { pxtorem: { rootValue: 50, }, }, }, }; ``` • After: ```js title="rspack.config.mjs" 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`. ```js title="rspack.config.mjs" export default { module: { rules: [ { test: /\.css$/, use: [ { loader: 'postcss-loader', options: { postcssOptions: { plugins: [['autoprefixer']], }, }, }, ], type: 'css', }, ], }, }; ``` You can refer to the [examples/postcss-loader](https://github.com/rstackjs/rstack-examples/tree/main/rspack/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: ```js import { Stats } from '@rspack/core/dist/stats'; // not supported since 0.3 ``` • After: ```js import { Stats } from '@rspack/core'; ``` ## 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: ```js 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](/guide/features/web-workers.md). ### `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: ```js title="rspack.config.mjs" import { defineConfig } from '@rspack/cli'; 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](https://github.com/rstackjs/rstack-examples/tree/main/rspack/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. ```sh $ RSPACK_PROFILE=ALL rspack build ``` For more detailed information about Profile, see [Performance Profiling](/guide/optimization/profile.md). 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](https://github.com/orgs/web-infra-dev/projects/9). ### 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](https://rsbuild.rs/), which is an out-of-the-box solution. This solution helps developers easily develop Vue.js applications using Rspack. --- # Source: https://rspack.dev/blog/announcing-0-4.md _November 02, 2023_ # 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](https://rsbuild.rs/) 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](https://v0.rspack.rs/config/builtins) code transformation features, [target](/config/target.md), and custom [rules\[\].type](/config/module-rules.md#rulestype). 1. Removal of support for some [builtins](https://v0.rspack.rs/config/builtins) features: - [builtins.relay](https://v0.rspack.rs/config/builtins#builtinsrelay): moved to `rspackExperiments.relay` - [builtins.react](https://v0.rspack.rs/config/builtins#builtinsreact): moved to `jsc.transform.react` - [builtins.emotion](https://v0.rspack.rs/config/builtins#builtinsemotion): moved to `rspackExperiments.emotion` - [builtins.pluginImport](https://v0.rspack.rs/config/builtins#builtinspluginimport): moved to `rspackExperiments.import` - [builtins.decorator](https://v0.rspack.rs/config/builtins#builtinsdecorator): moved to `jsc.parser.decorators` - [builtins.presetEnv](https://v0.rspack.rs/config/builtins#builtinspresetenv): moved to `jsc.env` ```js title="rspack.config.mjs" 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](/config/target.md) will not downgrade user-side code(including `node_modules`) ```diff title="rspack.config.mjs" 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](/config/module-rules.md#rulestype) 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](/config/experiments.md#experimentsrspackfuturedisabletransformbydefault) for the complete migration guide. Check out our previous discussion [here](https://github.com/web-infra-dev/rspack/discussions/4070). ### 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. ```diff title="rspack.config.mjs" + import ReactRefreshPlugin from '@rspack/plugin-react-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 ReactRefreshPlugin() ], }; ``` Checkout [here](/guide/tech/react.md#fast-refresh) 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](https://www.npmjs.com/package/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](/config/resolve.md#resolvetsconfig) for details. To opt out of the new resolver, set `experiments.rspackFuture.newResolver` to `false`. ## Migration guide There is a [migrate example](https://github.com/rstackjs/rstack-examples/pull/2) 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` ```diff title=package.json { "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 ```js { 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](#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](#deprecating-builtinreactrefresh). ### Migrating builtin options to builtin plugins In v0.4.0, Rspack deprecated some of the builtin options and migrated them to [builtin plugins](/config/plugins.md). 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: ```diff title="rspack.config.mjs" + import { rspack } from '@rspack/core'; 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](/plugins/rspack/html-rspack-plugin.md): ```diff title="rspack.config.mjs" + import { rspack } from '@rspack/core'; 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: ```js title="rspack.config.mjs" import { rspack } from '@rspack/core'; 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](/plugins/rspack/copy-rspack-plugin.md). For the original `builtins.minifyOptions`, we provide [SwcJsMinimizerRspackPlugin](/plugins/rspack/swc-js-minimizer-rspack-plugin.md): ```js title="rspack.config.mjs" import { rspack } from '@rspack/core'; export default { optimization: { minimizer: [ new rspack.SwcJsMinimizerRspackPlugin({ // minimizer configuration }), ], }, }; ``` Other builtin options can be directly referred to the rspack [builtin plugins](/config/plugins.md) for migration, or completed according to the CLI prompts after upgrading to v0.4.0. --- # Source: https://rspack.dev/blog/announcing-0-5.md _January 09, 2024_ # Announcing Rspack 0.5 ## Major feature updates ### Module Federation added to Rspack Checkout [this blog](/blog/module-federation-added-to-rspack.md) 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](/config/module-rules.md#rulestype). These `rules[].type`s 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: ```js title="rspack.config.mjs" 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: ```js title="rspack.config.mjs" 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: ```js title="rspack.config.mjs" 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](/config/target.md) 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`: ```diff title="rspack.config.mjs" 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: ```js title="rspack.config.mjs" 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](/blog/announcing-0-4.md#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](/blog/announcing-0-4.md#deprecating-default-transformation). ### 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](/config/experiments.md#experimentsrspackfuturedisableapplyentrylazily), 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](https://rspack.rs/blog/announcing-0.4#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. ```diff 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. ```sh [npm] npm install @swc/helpers ``` ```sh [yarn] yarn add @swc/helpers ``` ```sh [pnpm] pnpm add @swc/helpers ``` ```sh [bun] bun add @swc/helpers ``` ```sh [deno] deno add npm:@swc/helpers ``` If you are using `@rspack/plugin-react-refresh`, now you need to install `react-refresh` as devDependencies of your project. ```sh [npm] npm install react-refresh ``` ```sh [yarn] yarn add react-refresh ``` ```sh [pnpm] pnpm add react-refresh ``` ```sh [bun] bun add react-refresh ``` ```sh [deno] deno add npm:react-refresh ``` ### 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. ```diff 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. ```diff 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'); ``` --- # Source: https://rspack.dev/blog/announcing-0-6.md _April 10, 2024_ # 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](/plugins/rspack/css-extract-rspack-plugin.md#cssextractrspackplugin). ```js title="rspack.config.mjs" import { rspack } from '@rspack/core'; export default { plugins: [new rspack.CssExtractRspackPlugin()], module: { rules: [ { test: /\.css$/i, use: [rspack.CssExtractRspackPlugin.loader, 'css-loader'], }, ], }, }; ``` > There is an basic [project example](https://github.com/rstackjs/rstack-examples/tree/main/rspack/react-with-extract-css). ### 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`](/config/module.md#moduleparsercssauto) and [`module.generator`](/config/module.md#modulegeneratorcssauto) 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](https://caniuse.com/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`](/plugins/rspack/css-extract-rspack-plugin.md). 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](https://github.com/rstackjs/rstack-examples/tree/main/rspack/css-parser-generator-options) 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: ```js // Before v0.6.0, only default export was supported import classes from './index.module.css'; // Now, in addition to default export, it also supports: // Namespace exports import * as classes from './index.module.css'; // Named exports import { class1, class2 } from './index.module.css'; // Default and named exports used together import classes, { class1, class2 } from './index.module.css'; ``` 3. The default value of `namedExports` changed from `false` to `true`, meaning you'll have to use a namespace import (like `import * as classes from './style.css'`) or named import (like `import { class1 } from './style.css'`) by default, which will improve future compatibility with [native CSS module](https://web.dev/articles/css-module-scripts). 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](https://github.com/css-modules/css-modules), consistent with [`css-loader`'s `modules.auto: true`](https://github.com/webpack/css-loader?tab=readme-ov-file#auto), which will [simplify the writing rules for using less or sass with CSS Modules](https://github.com/webpack/webpack/issues/16572). ### 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. ```bash 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`. ```js title="rspack.config.mjs" 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`. ```diff title="rspack.config.mjs" + import { rspack } from '@rspack/core'; - import CssExtract from 'mini-css-extract-plugin'; 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: ```diff title="rspack.config.mjs" 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`](/config/module-rules.md#rulesparser) and [`rules[].generator`](/config/module-rules.md#rulesgenerator) 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](https://swc.rs/docs/plugin/selecting-swc-core#090x) of SWC. --- # Source: https://rspack.dev/blog/announcing-0-7.md _May 28, 2024_ # Announcing Rspack 0.7 ![](https://assets.rspack.rs/rspack/rspack-banner-v0-7.png) 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](#support-for-lazy-compilation): Significantly improves the dev startup performance of large applications by compiling on demand. - [Faster CSS Build](#faster-css-builds): Introducing a new css-module-lexer, which increases CSS bundling speed by 4 times. - [Breaking changes](#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: ```js title="src/a.js" 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. ![lazy-compilation-compare](https://assets.rspack.rs/rspack/assets/lazy-compilation-compare.png) ### How to use Now, you can enable the lazy compilation feature in Rspack through the [experiments.lazyCompilation](/config/experiments.md#experimentslazycompilation) configuration: ```js title="rspack.config.mjs" 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](https://github.com/web-infra-dev/rspack/issues). ## Faster CSS builds In v0.7, we have refactored the internal implementation of the [experiments.css](/config/experiments.md#experimentscss). For CSS dependency analysis, we have developed [css-module-lexer](https://github.com/ahabhgk/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: ```css title="style.module.css" :local(.parent):global(.child) > ul { color: red; } ``` The CSS parsing process before and after the refactor is shown in the diagram below: ![rspack-css-lexer](https://assets.rspack.rs/rspack/assets/rspack-css-lexer.png) `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](https://github.com/web-infra-dev/rspack/pull/6448), [rspack#6505](https://github.com/web-infra-dev/rspack/pull/6505). ### CSS @import rules must precede all other rules In Rspack 0.7, we have partially refactored the internal implementation of [experiments.css](/config/experiments.md#experimentscss). 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. ```bash 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](https://swc.rs/docs/plugin/selecting-swc-core#091x) 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](https://rsbuild.rs/community/releases/v0-7) to learn more. --- # Source: https://rspack.dev/blog/announcing-1-0-alpha.md _June 29, 2024_ # Announcing Rspack 1.0 alpha ![](https://assets.rspack.rs/rspack/rspack-banner-v1-0-alpha.png) 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. ```js title="rspack.config.mjs" 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](https://github.com/parcel-bundler/lightningcss). 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. ```diff title="rspack.config.mjs" export default { optimization: { minimizer: [ // The default CSS minimizer changed: - new rspack.SwcCssMinimizerRspackPlugin() + new rspack.LightningCssMinimizerRspackPlugin() ], }, }; ``` You can switch back to `SwcCssMinimizerRspackPlugin` by following configuration. ```js 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](https://lightningcss.dev/minification.html#unused-symbols) 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](https://github.com/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](/guide/features/builtin-swc-loader.md#jscexperimentalplugins) in `builtin:swc-loader`. So we have removed the built-in plugins from the Rspack core, including: - [@swc/plugin-emotion](https://www.npmjs.com/package/@swc/plugin-emotion) - [@swc/plugin-relay](https://www.npmjs.com/package/@swc/plugin-relay) - [@swc/plugin-styled-components](https://www.npmjs.com/package/@swc/plugin-styled-components) Take `@swc/plugin-styled-components` as an example. In v1.0, you can use it as follows. - Installation: ```bash npm i @swc/plugin-styled-components -D ``` - Configuration: ```diff 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](/config/experiments.md#experimentscss) 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](https://github.com/webpack/css-loader) and [mini-css-extract-plugin](https://github.com/webpack/mini-css-extract-plugin) to generate standalone CSS files. 2. Use [css-loader](https://github.com/webpack/css-loader) and [style-loader](https://github.com/webpack/style-loader) to inject CSS through `