René's URL Explorer Experiment

Title: fix(@angular/build): respect tsconfig customConditions in unit-test builder by RobbyRabbitman · Pull Request #33246 · angular/angular-cli · GitHub

Open Graph Title: fix(@angular/build): respect tsconfig customConditions in unit-test builder by RobbyRabbitman · Pull Request #33246 · angular/angular-cli

X Title: fix(@angular/build): respect tsconfig customConditions in unit-test builder by RobbyRabbitman · Pull Request #33246 · angular/angular-cli

Description: PR Checklist Please check to confirm your PR fulfills the following requirements: 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 What kind of change does this PR introduce? 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? When @angular/build:unit-test is configured with an @angular/build:ng-packagr build target, the synthesized application-builder build never receives the test tsconfig's compilerOptions.customConditions. Module resolution therefore diverges from ng build, which honors customConditions natively through ng-packagr: transformNgPackagrOptions() only forwards stylePreprocessorOptions, assets and inlineStyleLanguage from ng-package.json; ng-packagr's schema has no conditions field, so nothing is carried over. The synthesized ApplicationBuilderInternalOptions is then handed to buildApplicationInternal() without conditions, so esbuild resolves library imports with only the default conditions (module, development/production, plus browser/node). The Vitest runner's resolve.conditions was hardcoded to ['es2015', 'es2020', 'module', (browser)], also ignoring custom conditions. Concrete impact: monorepo setups that use customConditions (e.g. a source condition) to redirect workspace library imports to local TypeScript sources during development work as expected for ng build, but ng test silently falls back to the published entry points — defeating the purpose of source‑mapped local development and making library tests harder to debug. Issue Number: N/A What is the new behavior? The unit-test builder now reads compilerOptions.customConditions from the test tsconfig (following the extends chain via the TypeScript config parser) and: forwards them as conditions into the synthesized application-builder options, but only when the build target did not already set conditions. This preserves the existing application-builder behavior, including explicit opt‑outs (conditions: []) and user-supplied lists. appends them to Vite's resolve.conditions in the Vitest plugin, so the runner's own resolver matches the build-time resolution. No schema changes and no public API surface changes; the new behavior is opt‑in via the existing compilerOptions.customConditions tsconfig field (TS 5.0+). A new integration spec at packages/angular/build/src/builders/unit-test/tests/options/conditions_spec.ts locks the behavior in with two cases: Positive – with customConditions: ['staging'] in tsconfig.spec.json and a #target imports map that exposes the good source only under the staging condition, the spec resolves to the good source and passes. Negative regression guard – same target mapping but no customConditions declared; the spec must fall back to the default (bad) target, proving the new behavior is opt‑in and does not inject unrelated conditions. Does this PR introduce a breaking change? Yes No The new behavior only activates when compilerOptions.customConditions is present in the test tsconfig — a field most projects do not set today. For @angular/build:application build targets that explicitly set conditions, that value is preserved (the backfill is guarded by conditions === undefined). For ng-packagr targets, this brings ng test into parity with ng build, which is a convergence rather than a divergence. Other information Files changed: packages/angular/build/src/builders/unit-test/options.ts — read customConditions from the test tsconfig via ts.parseJsonConfigFileContent (extends‑aware) and expose it on the normalized options. packages/angular/build/src/builders/unit-test/builder.ts — backfill conditions into the application-builder options only when the build target did not set it. packages/angular/build/src/builders/unit-test/runners/vitest/executor.ts — thread customConditions through to the Vitest config plugin. packages/angular/build/src/builders/unit-test/runners/vitest/plugins.ts — append customConditions to Vite's resolve.conditions. packages/angular/build/src/builders/unit-test/tests/options/conditions_spec.ts — new integration spec. The Karma runner intentionally was not touched: it does not share the Vite resolver code path, and forwarding conditions through the application build it consumes is already covered by the same builder.ts change.](#33246)

Open Graph Description: PR Checklist Please check to confirm your PR fulfills the following requirements: The commit message follows our guidelines: https://github.com/angular/angular-cli/blob/main/CONTRIBUTING.md#-comm...

X Description: PR Checklist Please check to confirm your PR fulfills the following requirements: The commit message follows our guidelines: https://github.com/angular/angular-cli/blob/main/CONTRIBUTING.md#-comm...

Opengraph URL: https://github.com/angular/angular-cli/pull/33246

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width