Lightning CSS loader
Lightning CSS is a high performance CSS parser, transformer and minifier written in Rust. It supports parsing and transforming many modern CSS features into syntax supported by target browsers, and also provides a better compression ratio.
Rspack provides a built-in builtin:lightningcss-loader, which is based on Lightning CSS to transform CSS. It can replace the postcss-loader and autoprefixer for CSS syntax downgrading, prefixing, and other functionalities, offering better performance.
Please note that Lightning CSS strictly requires standards-compliant CSS input. When non-standard CSS is processed by the builtin:lightningcss-loader, styles may be ignored or produce unexpected results (Undefined Behavior). To ensure that styles are correctly applied, avoid using non-standard CSS syntax or browser-specific proprietary syntax, and instead use standard CSS writing practices that conform to W3C specifications.
Example
To use builtin:lightningcss-loader in your project, you need to configure it as follows.
Type declarations
You can use the LightningcssLoaderOptions type exported by @rspack/core to enable type hints:
Options
Below are the configurations supported by builtin:lightningcss-loader. For detailed configuration, please refer to lightningcss document.
targets
- Type:
string | string[] | Targets
Browserslist query string or a Targets object specifying browser versions.
When targets is not set, the loader gets its browser targets from Rspack's target. For example, with browserslist or browserslist:modern, you do not need to repeat the configuration in the loader. Lightning CSS only supports browser targets, so it cannot get browser versions from non-browser targets such as node.
When Rspack target is not set, the loader also tries to get browser targets from its default value. See target default behavior for details.
If no Browserslist configuration is found, Rspack defaults to web, which does not specify browser versions. The loader's targets then remains unset, and you can configure it as needed.
Here are some examples of setting targets.
- Setting a browserslist query string:
- Setting an array of browserslist query strings:
- Setting a
Targetsobject:
errorRecovery
- Type:
boolean - Default:
true
Control how Lightning CSS handles invalid CSS syntax.
By default, this option is enabled, meaning that when invalid CSS rules or declarations are parsed, Lightning CSS will skip them and emit warnings, while omitting them from the final output without interrupting the compilation process.
Ignoring warnings
If you confirm that these warnings can be ignored, you can use ignoreWarnings to filter out the warnings from LightningCSS.
For example, ignore all warnings:
You can also use regular expressions to ignore specific warnings.
Disabling errorRecovery
If you set errorRecovery to false, Lightning CSS will throw a compilation error and interrupt the build process when parsing any invalid CSS syntax:
drafts
- Type:
{ customMedia?: boolean } - Default:
undefined
Enable parsing of draft CSS syntax.
Set drafts.customMedia to true to parse @custom-media rules. The loader expands custom media references and removes their definitions when include.customMediaQueries is set or when browser targets are configured. Lightning CSS treats custom media as unsupported in every browser, so any browser targets enable this transform, including targets derived from Rspack's target. Set exclude.customMediaQueries to keep custom media unchanged. Because include takes precedence over exclude and include.mediaQueries already contains include.customMediaQueries, this only works when both include.customMediaQueries and include.mediaQueries are disabled.
For example, with drafts: { customMedia: true } and include: { customMediaQueries: true }, the following CSS:
is transformed into:
Custom media is resolved within each CSS file. If a file uses a name that it doesn't define, the loader emits a warning and leaves all custom media in that file unchanged. A circular definition causes a build error. Lightning CSS does not expand custom media in @import conditions, so in a file that uses custom media there, the loader also leaves all custom media unchanged.
Sharing custom media between files
To use the same definitions in several files, add them to each file before this loader runs. For example, with a small loader that appends a shared file:
this.addDependency() rebuilds each file when the shared definitions change. Definitions can come after the queries that use them, so appending keeps @import rules first and source map positions unchanged. Appended definitions override definitions with the same name in the file.
Alternatively, leave custom media to LightningCssMinimizerRspackPlugin, which resolves it across each output CSS file. Enable minimizerOptions.drafts.customMedia in the plugin, and leave drafts.customMedia disabled in this loader, or set exclude.customMediaQueries with both include.customMediaQueries and include.mediaQueries disabled, so that the loader keeps the definitions. Custom media is then only expanded in minimized output, and each name must be defined in the same output file as the queries that use it.

