RFC: Porting MiniCssExtract to Rspack

[JSerFeng]

Motivation

Many loaders in ecosystem needs css-loader, there are 2 main reasons why we need this while we already have native css support

1. Many loaders are developed based on css-loader, for example CSS can import assets using url() syntax, using traditional css-loader, it treats them as importing other modules, while using native css, it treats them as asset modules. If we want to use css-loader, we better provide a way to extract css into modules, for now users can only use style-loader to inject styles at runtime.
2. Currently native css parsers/transformers don't stable, lightningCSS doesn't support some css modules syntax, CSS parser is well maintained but still encountered issues from time to time, and once it has issue.

Implement

CssExtractPlugin consists of 2 parts, loader and plugin.

Loader

css-loader result is javascript modules, simplified code is like:

module.exports = [
  { identifier: "foo.css", content: "body{}", sourceMap: "..." },
  { identifier: "bar.css", content: "html{}", sourceMap: "..." },
]

In order to get all CSS information like content and sourceMap, we need to evaluate this code, so we can use loaderContext.importModule and pitch loader to do it.

Normal loader execution order:

other css preprocessor ->  css-loader -> extract-loader

Pitch loader execution order is in reverse:

extract-loader -> css-loader -> other css preprocessor

In extract-loader, using this.importModule(``${this.resourcePath}.webpack[javascript/auto]!=!!!${request}``) to evaluate css-loader result. And once we get result, we put them in the additionalData of loaders. Then we return empty module if not using CSS modules, otherwise return CSS modules mappings.

export default {  }

Plugin

In plugin, we need to wrap original javascript parser, and check if additionalData has css related data. If not, parse it as normal javascript module, if so, we need to extract those css information like contents, sourceMaps etc.

Then we creates dependencies based on this.

struct CSSDependency {
  identifier: String,
  content: String,
  source_map: Option<String>,
}

And add those dependencies to original javascript module.

In Rspack arch, module dependency needs according Module factory to constructs module. We registered CSSModuleFactory to generate CSSModule for CSSDependency.

impl CSSModule {
  pub fn new(identifier: String, content: String, source_map: Option<String>) -> Self { ... }
}

In the end, the relationship is like:

At render_manifest phase, pick chunks that contains CSS modules, and render modules by their order.
Some modules may have conflict order in different chunks, the sorting algorithm is here.

Runtime

We can reuse some runtime in native CSS, there runtime modules are basically the same, create style tag to load styles, but this plugin has more options to change inject position, loading ways etc.

Add css chunk loading handler, when loading chunks, we check if chunk contains css, if so, creates a style tag to load style, runtime parts is totally the same of mini-css-extract-plugin