[Bug]: SCSS/SASS Source Maps do not resolve @import directives

[dretsa]

Version

System:
    OS: macOS 15.1
    CPU: (14) arm64 Apple M4 Pro
    Memory: 8.73 GB / 48.00 GB
    Shell: 5.9 - /bin/zsh
  Browsers:
    Chrome: 132.0.6834.111
    Edge: 132.0.2957.127
    Safari: 18.1

Details

When source maps are enabled for SCSS and you @import directive is used, the source is always index.scss instead of the imported file.
I am using the defaults for the most part, the only change is output.sourceMap.css: true. I have also tried setting all sassLoaderOptions.sassOptions.sourceMap*: true - no effect. It seems like source maps for CSS -> SCSS and CSS extraction are working but the SCSS source maps are not properly output.

I am using bootstrap - I can provide a quick repo with reproduction.

Reproduce link

https://github.com/dretsa/rsbuild-scss-sourcemap-bug

Reproduce Steps

1. Pull repo
2. Run npm ci
3. Run npm run dev
4. Inspect the alert element in your browser

[dretsa]

Also added another SCSS file in the reproduction repo to test. The other file is properly shown in source maps so this only affects @import. Imports from JS are correctly source-mapped.

[chenjiahan]

From what I understand about Sass, when using the @import syntax, all imports are merged into the main file, which may result in a source map that maps all styles to the main file (in this case index.scss).

[chenjiahan]

Maybe you can try other tools, such as webpack + sass-loader, I think we will see the same results

[dretsa]

I've had sourcemaps working before on @import syntax. I will try with another tool and report here

[dretsa]

I managed to get sourcemaps working with webpack quite easily - see: https://github.com/dretsa/rsbuild-webpack-scss-sourcemaps

1. Pull repo
2. Run npm ci
3. Run npm run build
4. Open dist/index.html

[chenjiahan]

Thanks for providing the webpack reproduction. After trying it, I can confirm that the Sass source map is broken by other loaders.

In Rsbuild, both resolve-url-loader and lightningcss-loader cause this. If we disable these two loaders, we can get the same result in Rsbuild as the webpack demo.

import { defineConfig } from '@rsbuild/core';
import { pluginSass } from '@rsbuild/plugin-sass';

export default defineConfig({
  plugins: [
    pluginSass({
      rewriteUrls: false,
    }),
  ],
  output: {
    sourceMap: true,
  },
  tools: {
    lightningcssLoader: false,
  },
});

But resolve-url-loader and lightningcss-loader both play important roles, we can't remove them from Rsbuild.

[dretsa]

Thank you for checking! I am not suggesting removing them at all.

I had a quick look if LightningCSS supports sourcemaps and they have an option to pass in sass source maps using the inputSourceMap API. I assume you're loading their library directly in Rust, so not sure if you can pass this to the library.

resolve-url-loader looks kind of dead, with last commit 3 years ago, but it also seems to support source maps

[chenjiahan]

The resolve-url-loader relies on adjust-sourcemap-loader, which causes performance regression in some scenarios, so Rsbuild has disabled the sourceMap option of resolve-url-loader.

To solve this issue, I think that we need to invest in two aspects:

• Investigate the source map implementation of lightningcss-loader
• Find an alternative to resolve-url-loader, such as implementing a new lightningcss-based loader to replace it.

[dretsa]

Considering the main features of SASS are now supported with plain CSS I'm not sure how worth it is implementing this. If it's possible to fix the performance regressions with resolve-url-loader, I would be happy to fork it and help but I don't think this should be a high priority bug. I would only need some guidance where the performance regression is happening.

[chenjiahan]

resolve-url-loader uses adjust-sourcemap-loader, and some of our internal projects have experienced significant performance degradation caused by adjust-sourcemap-loader.

I agree that this issue is not a high priority, so we cannot give a promised time to resolve it.