August 24, 2023
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.
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:
• After:
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
.
You can refer to the examples/postcss-loader for a complete example.
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:
• After:
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:
For more information about web workers support, see web workers.
builtin:swc-loader
SupportAlthough 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:
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.
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.
For more detailed information about Profile, see Performance Profiling.
Alignment with More APIs
splitChunks.chunks
supports regex.splitChunk.\{cacheGroup\}.type
.splitChunk.\{cacheGroup\}.idHint
.ensureChunkConditionsPlugin
.rule.use
supports functions.configuration.profile
.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.
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.
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.