Can't resolve SCSS files in karma with "builderMode": "application"

[Nvveen]

Command

test

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

No response

Description

Using a codebase with large amounts of older SCSS, code and configurations, I ran into some change detection mishaps in a lot of unittests that have been migrated to use signals. To avoid this, I tried to switch over the "builderMode" to "application" to see if that might alleviate some of these errors. However, I didn't get that far, because as soon as I added that option, I got build errors in ng test where it wasn't able to resolve the location of SCSS files in src/assets (that are referred to in the stylesheets like so: `@import 'assets/scss/variables'.

Minimal Reproduction

I have made a full reproduction at https://stackblitz.com/edit/stackblitz-starters-c6wauz2h?file=angular.json

The key thing here is that removing "builderMode" in angular.json` and the test builds and runs. Adding it and the error occurs.

Exception or Error

✘ [ERROR] Could not resolve "assets/scss/variables" [plugin angular-compiler]

    angular:styles/component:css;f13b6986812740f0b03d6a6aa6a2838352a605dfe351f63e146008c4b3472985;/home/projects/stackblitz-starters-knyg36db/src/app.component.ts:2:10:
      2 │   @import 'assets/scss/variables';
        ╵           ~~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path "assets/scss/variables" as external to exclude it from the bundle, which will remove this error and leave the unresolved path in the bundle.
  The plugin "angular-compiler" was triggered by this import

    src/app.component.ts:2:33:
      2 │ ...CE__0 from "angular:jit:style:inline;CiAgQGltcG9ydCAnYXNzZXRzL3N...

Your Environment

❯ ng version

     _                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/
    

Angular CLI: 19.1.6
Node: 18.20.3
Package Manager: npm 10.2.3
OS: linux x64

Angular: 19.1.5
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1901.6
@angular-devkit/build-angular   19.1.6
@angular-devkit/core            19.1.6
@angular-devkit/schematics      19.1.6
@angular/build                  19.1.6
@angular/cli                    19.1.6
@schematics/angular             19.1.6
rxjs                            7.8.1
typescript                      5.6.3
zone.js                         0.15.0

Anything else relevant?

No response

[Nvveen]

Switching to @use 'assets/scss/variables' as *; does work, but migrating away from @import is not feasible for us in the short-term because of the size of our codebase and certain requirements.

[alan-agius4]

This behavior is working as expected. By default, deprecation warnings in Sass are treated as fatal errors. However, you can opt out of this by configuring the sass option under stylePreprocessorOptions in your angular.json.

"architect": {
  "build": {
    "builder": "@angular-devkit/build-angular:application",
    "options": {
      "outputHashing": "none",
      "namedChunks": true,
      "stylePreprocessorOptions": {
        "sass": {
          "futureDeprecations": ["color-functions"],
          "fatalDeprecations": ["color-functions"],
          "silenceDeprecations": ["1.77.0"]
        }
      }
    }
  }
}

For more details, refer to the Sass docs:
https://sass-lang.com/documentation/js-api/interfaces/options/

[Nvveen]

This behavior is working as expected. By default, deprecation warnings in Sass are treated as fatal errors. However, you can opt out of this by configuring the sass option under stylePreprocessorOptions in your angular.json.

Well, this is definitely different from my original problem. Your code sample shows the configuration for the application builder, whilst my example is about running karma with the application builder. Furthermore, "sass" is not even an option in `"stylePreprocessorOptions" for the "test" configuration (why is beyond me, I tried finding another issue that mentioned this, but was unable to).

[alan-agius4]

A feature request has been made to support this option in the Karma builder: #29185. In the end, it's due to the same underlying issue that using deprecated syntax will cause Sass to fail by default.

[Nvveen]

Yes, that was the issue I was trying to find. We are also running Bootstrap. I assume the problem here then is that build-angular:karma uses the browser builder internally? I'm not sure whether we had to fix SASS imports issues when we switched to esbuild (I know we didn't have to last month when we switched to application). Is there any hope of the karma builder being migrated to application? Because even if #29185 gets resolved, just surpressing the errors isn't necessarily the problem, it literally fails to compile the SASS files.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}