…uilder
The unit-test builder synthesizes an application-builder build from the
configured buildTarget. The application builder forwards `conditions` into
esbuild's `build.initialOptions.conditions`, and the Angular compiler plugin
in turn assigns that array onto the in-plugin TypeScript program's
`compilerOptions.customConditions`. When the buildTarget is
`@angular/build:ng-packagr`, the synthesized application options never set
`conditions` (ng-packagr has no such schema field; it honors
`compilerOptions.customConditions` natively at the tsconfig level instead).
As a result both esbuild and the TypeScript program resolve with default
conditions only, diverging from `ng build` and silently breaking monorepo
setups that use `customConditions` to redirect workspace library imports to
local sources during development.
Read `compilerOptions.customConditions` from the test tsconfig (following
the `extends` chain via `ts.parseJsonConfigFileContent`) and:
- forward them as `conditions` to the synthesized application build, but
only when the buildTarget did not already set `conditions` (preserves
application-builder behavior including explicit `conditions: []` and
user-supplied lists), and
- append them to Vite's `resolve.conditions` so the Vitest runner's own
resolver matches the build-time resolution.
This aligns esbuild, the compiler plugin's TypeScript program, and Vitest
on the same condition set without introducing new options or schema fields;
the new behavior is opt-in via the existing tsconfig field.