Missing options for Vitest config (Library Builder)

[ms-dosx86]

Which @angular/* package(s) are the source of the bug?

Don't known / other

Is this a regression?

No

Description

I wanted to migrate from Karma to experimental Vitest test runner but unfortunately couldn't make it due to lack of "stylePreprocessorOptions" property in configuration file. Is it just missing or are there other ways to include paths to shorten SCSS imports?

Here is my setup

            "stylePreprocessorOptions": {
              "includePaths": [
                "projects/ui-kit/styles/",
                "projects/ui-kit/styles/components/"
              ]
            }

And in components I would

@use 'mixins' as mixins;

Please provide a link to a minimal reproduction of the bug

No response

Please provide the exception or error you saw

Please provide the environment you discovered this bug in (run ng version)

Angular CLI: 20.0.2
Node: 22.12.0
Package Manager: npm 10.9.0
OS: darwin arm64

Angular: 20.0.3
... animations, cdk, common, compiler, compiler-cli, core, forms
... language-service, localize, platform-browser
... platform-browser-dynamic, platform-server, router

Package                      Version
------------------------------------------------------
@angular-devkit/architect    0.2000.2
@angular-devkit/core         20.0.2
@angular-devkit/schematics   20.0.2
@angular/build               20.0.2
@angular/cli                 20.0.2
@angular/ssr                 20.0.2
@schematics/angular          20.0.2
ng-packagr                   20.0.0
rxjs                         7.8.1
typescript                   5.8.3
zone.js                      0.15.0

Anything else?

No response

[alan-agius4]

The stylePreprocessorOptions options are inhered from the build target.

[ms-dosx86]

Thank you. Good to know

[ms-dosx86]

@alan-agius4 I just realised that in my case the project is a library and angular doesn't allow to set "stylePreprocessorOptions" in the build target's options. AFAIK the official way to do this is to use "styleIncludePaths" in ng-package.json. But this doesn't work in unit testing so that was the reason why I used "stylePreprocessorOptions" specifically for test options. So how else do we do it or am I missing something?

[alan-agius4]

You're right, the builder options for libraries aren't inherited, and this is an area that still needs improvement.

[angular-robot[bot]]

This feature request is now candidate for our backlog! In the next phase, the community has 60 days to upvote. If the request receives more than 20 upvotes, we'll move it to our consideration list.

You can find more details about the feature request process in our documentation.

[heddendorp]

I would like to add externalDependencies as another config option that would be very good to have in the test config.

[angular-robot[bot]]

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.

[angular-robot[bot]]

Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.

We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.

You can find more details about the feature request process in our documentation.

[wvankuipers]

@alan-agius4 Not sure this is a feature, Vitest is unusable now if you have a library that makes use of the stylePreprocessorOptions. I'm guessing this issue will get more traction soon now Vitest is publicly available and projects will start migrating towards it.

[jonaskuske]

Vitest seems unsuable in general with a library, as it does not correctly compile NgModules and ng-packagr has no option to disable AOT. You can disable in the module's decorator, but not conditionally (like aot: !!process.env.VITEST), so I had to add a separate build target using @angular/build:application and aot: false and am using this as buildTarget for the unit tests, while the regular library build keeps using ng-packagr. Quite the workaround, but allowed me to fully migrate

[hamfastgamgee]

I ended up having to create a separate build target only for my existing karma tests to specify the zone polyfills after migrating to unit-test in a library, which is basically just another flavor of this same issue. I was a little surprised when it worked, to be honest. I could live with that as a pattern even if it's unintuitive as long as there was guidance to do so.