fix(@angular/build): resolve unit-test include patterns from the project root

[thekhegay]

PR Checklist

• The commit message follows our guidelines
• Tests for the changes have been added
• Docs have been added / updated

PR Type

• Bugfix

What is the current behavior?

Issue Number: #33467

Schema says include is relative to project root. Code resolves it from source root. So for a library with secondary entry point next to src nothing reaches it - my-sub-package/**/*.spec.ts, ./my-sub-package/**/*.spec.ts, my-sub-package/my-sub.spec.ts, projects/my-lib/my-sub-package/**/*.spec.ts all find zero files and run still says success. Happens with no config too, ng generate library writes no include.

What is the new behavior?

Pattern that matched nothing under source root gets retried from project root. Pattern that already matched is not retried, so **/*.spec.ts stays where it is and does not start picking up specs outside src. Project rooted at workspace root is never retried, that would search every project.

Checked on generated workspace with library, secondary entry point and an e2e/ spec. Four spellings above fixed plus reporter's ["**/*.spec.ts", "my-sub-package/**/*.spec.ts"]. Six spellings that work today return same files. e2e/ spec not picked up before or after.

Cost is globbing per pattern instead of batching, needed to tell unmatched from matched. On library with 302 specs medians are 451ms before and 447ms after, spread between rounds is wider than that.

builders/karma/find-tests.ts untouched, it calls through without new argument so karma keeps current behavior.

Three of five new cases fail without the change. Other two pin what must not move.

Does this PR introduce a breaking change?

• Yes
• No

[gemini-code-assist]

Code Review

This pull request updates the unit test builder to retry finding test files from the project root if they are not found under the project source root, aligning with the builder's schema. The findTests function is refactored to use a helper collectTests to perform this search. Feedback on the changes points out a redundant ternary check when calling glob, as dynamicPatterns is guaranteed to be non-empty at that point.

[clydin]

Thank you for the contribution.
However, in this case the schema documentation is actually incorrect. The project source root is the expected base path for include and exclude.

For existing library projects, using parent traversal is the recommended solution:

"include": ["**/*.spec.ts", "../my-sub-package/**/*.spec.ts"]

However, for the in-development new library build system. The path constraints for secondary entrypoints will no longer be present. This will allow all source files to reside within the actual project source root in the future.

[thekhegay]

@clydin thanks, that is clear. Should have looked for that answer before writing code.

Want me to send small PR fixing two descriptions in unit-test/schema.json? Both include and exclude say "relative to the project root"

[clydin]

Already done and merged but thank you for the offer.