[thekhegay]

PR Checklist

• The commit message follows our guidelines: https://github.com/angular/angular-cli/blob/main/CONTRIBUTING.md#-commit-message-guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• Other... Please describe:

What is the current behavior?

Issue Number: N/A

use-library-builder drops style options of secondary entry points
ng-packagr's own scss-paths sample shows it: sub-module/ng-package.json has own styleIncludePaths, after migration sub-module/assets is just gone from includePaths

findSecondaryEntryPoints reads only lib.entryFile from secondary config and then file is deleted, so styleIncludePaths and sass set per entry point are lost (primary ones are migrated)
Small workspace with sub/ng-package.json setting "styleIncludePaths": ["../styles", "./styles"] builds fine with ng-packagr, after migration ng build fails:

✘ [ERROR] Error: Can't find stylesheet to import.
  ╷
2 │ @use 'tokens';
  │ ^^^^^^^^^^^^^
  ╵
  ../../../../projects/lib/sub/b.component.scss 2:1  root stylesheet [plugin angular-sass]

Secondary sass.silenceDeprecations is lost too, so @import deprecation warning comes back

What is the new behavior?

Library builder has one global stylePreprocessorOptions, so include paths of secondary entry points are resolved from their own diretory and merged into includePaths after primary ones, duplicates removed
sass deprecation lists of all entry points are merged same way
Same workspace builds after migration (both packages built from this branch) and styles in output match ng-packagr build

New case in migration_spec.ts sets styleIncludePaths and sass on primary and on testing entry point, it fails on main

Does this PR introduce a breaking change?

• Yes
• No

Other information

Because options become global, partial with same name in two include paths now resolves to first one for every entry point
If you prefer warning for secondary options instead of merging, I can switch to that

Also lib.cssUrl: "none" is dropped without any message, library builder always inlines relative url() as data URI and has no such option
Should migration warn about it? Can add it here or in seperate PR

[gemini-code-assist]

Code Review

This pull request updates the use-library-builder migration schematic to collect and merge styleIncludePaths and sass options from secondary entry points. Feedback on the changes highlights an issue where existing sass options in the workspace configuration (angular.json) are overwritten rather than merged, and a code suggestion is provided to preserve and merge these existing options.

[clydin]

This PR was merged into the repository. The changes were merged into the following branches:

• main: c32a690