RFC-006: sass support

[ahabhgk]

• Start Date: 2022-07-12
• Linked PR:
• Related Issue:

Summary

This RFC proposes to add the ability to process sass/scss files for RSPack by sass-loader (or rspack_plugin_sass), which transforms the sass/scss syntax to CSS syntax, then leaves the CSS to rspack_plugin_css.

Motivation

Support sass for RSPack.

Detailed design

The sass/scss handling ability for RSPack mainly includes two parts, the loader and the sass compiler in rust.

sass compiler in rust

There are several implementations for sass in rust, choosing the right implementation is essential for both correctness and performance.

Rewrite in rust implementations like grass and rsass are incomplete for the sass-spec and unoptimized at some cases.

Wrap LibSass (which is written in cpp) in rust like sass-rs and sass-alt are also unrecommend because LibSass has already deprecated.

Embed dart-sass in rust has excellent support for sass-spec and consistent performance with dart-sass and LibSass, cause it's just dart-sass using a protocol to communicate with the host, like sass-embedded-host-node does but implement the host in rust.

the loader

input: sass/scss content string
output: CSS content string, source map

the loader uses the sass compiler above to compile sass/scss content.

Problems with url(...)

This problem also happens in webpack's sass-loader, parcel and vite, webpack has resolve-url-loader which uses sass's source map to relocate the URL and rewite it.

The root cause of the problem is how the dart-sass compiler resolves, the priority of the custom importer is lower than resolving a relative file in sass according to the sass API document, and doesn't support rewrite URLs for relative file as less does.

Since this is a behavior triggered by dart-sass, we could provide a resolve-url-loader for RSPack like webpack dose shortly, and support rewrites URLs once dart-sass officially supports it.

Should we support sass modern API

Sass has two sets of API, webpack sass-loader support both by api option, parcel and vite haven't supported it.

The sass modern API leads to different behavior for sassOptions, one of the biggest problems of sass modern API is it doesn't support custom resolve, alias, plugin resolve, etc. Since it will increase the user's mental burden, we should not support it for the loader for now.

Partial support for sassOptions

RSPack config file is JSON format and it does not support the js function, so the logger, function, and importer need the user to define js functions in sassOptions can't be implemented.

Prior Art

• webpack sass-loader
• parcel sass transformer
• vite sass preprocessor

Unresolved questions

• Naming: should we call it sass-loader (rspack_sass_loader) like webpack or call it rspack_plugin_sass.

• How to install dart-sass-embedded for user side: postinstall? optionalDependencies? or some better way to link it and rspack into one executable binary?

• loaderContext.addDependency for RSPack, this adds a file as a dependency of the loader result to make them watchable.

• loaderContext.getResolve for RSPack, the resolverFactory, which is needed to create a resolver for sass/scss file (extensions: [".sass", ".scss", ".css"], mainFiles: ["_index", "index"]) to implement webpackImporter, for now RSPack has an singleton resolver (extensions: [".tsx", ".jsx", ".ts", ".js", ".json"]) on plugin_driver, and it can't used for sass/scss file.

• loader pipelines for RSPack: for now, RSPack has a transform_include hook which is controlled by the plugin. For example, if we want rspack_plugin_css to handle the result of the sass-loader, we need rspack_plugin_css's transform_include to return true for the sass/scss file, which causes coupling. So it's needed to let the user control (or config) the transform_include as Rule.test or pipelines does. Or just coupling the sass/scss transform logic in the CSS plugin as vite does 😥.

  // in rspack_plugin_css
  fn transform_include(&self, uri: &str) -> bool {
    let extension = getExtension(uri);
    extension == "css" || extension == "scss" || extension == "sass" // coupling
  }

[hyf0]

I prefer the name spack_plugin_sass.

[h-a-n-a]

The implementation of the resolve-url-loader is a little bit hacky, could we provide a double pass (rewrite URL first and then do the sass compilation) to solve this issue?

[ahabhgk]

Great idea! But dart-sass compiler compiles sass/scss file and its all @import, @use dependencies together into one CSS file (this is also the reason why we need loaderContext.addDependency for RSPack), besides finding all url(...) kind import in sass way and rewrite it we also need to resolve all @import, @use dependencies in sass way and rewrite their url(...) kind import recursively. Not sure which way is better, I suggest separating it from this RFC and finding out after this RFC is implemented.