#cli: `@angular/build:ng-packagr` with `@angular/build:unit-test` does not respect `customConditions`

1 messages · Page 1 of 1 (latest)

feral void May 23, 2026, 10:11 AM

When executing @angular/build:ng-packagr via ng build it does respect tsconfig compilerOptions.customConditions which is nice, because we can resolve source files during local development in a monorepo. However, @angular/build:unit-test using @angular/build:ng-packagr as build target seems to drop/does not respect (?) compilerOptions.customConditions when running ng test. Site note: @angular/build:application has a conditions property in its schema and it works like a charm. Can you help me get it working for libs aswell?

{
  "version": 1,
  "cli": { "analytics": false },
  "projects": {
    "lib": {
      "projectType": "library",
      "root": "",
      "sourceRoot": "src",
      "architect": {
        "build": {
          "builder": "@angular/build:ng-packagr",
          "options": {
            "project": "ng-package.json",
            "tsConfig": "tsconfig.build.json"
          }
        },
        "test": {
          "builder": "@angular/build:unit-test",
          "options": {
            "buildTarget": ":build",
            "tsConfig": "tsconfig.spec.json",
            "browsers": ["chromium"],
            "watch": false,
            "coverage": true,
          }
        }
      }
    }
  }
}

rain caveBOT May 23, 2026, 10:11 AM

Hi @feral void. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

I'm sorry, but the knowledge sources do not contain enough information to fully answer your question about customConditions support in @angular/build:unit-test when using @angular/build:ng-packagr as the build target.

Here is what the knowledge sources do confirm:

@angular/build:application has a conditions option in its schema that allows specifying custom package resolution conditions. [CLI build docs]
@angular/build:unit-test has a build-target option that specifies the build target to use for the unit test build. [CLI test docs]
The ng build command for libraries uses @angular/build:ng-packagr, which is a different build system from the esbuild-based @angular/build:application. [Creating libraries]
The two build systems (esbuild-based for apps, ng-packagr for libs) support different things and behave differently. [Using your library]

However, the knowledge sources do not document:

Whether @angular/build:unit-test respects compilerOptions.customConditions from tsconfig when the build target is @angular/build:ng-packagr.
Whether there is a workaround or a supported conditions option for the library test scenario.
The internal behavior of @angular/build:unit-test with respect to TypeScript customConditions.

Recommendations based on what is known:

Check the runner-config option: You can provide a custom Vitest configuration file via runner-config in angular.json, which may allow you to configure resolution conditions at the Vitest/esbuild level. However, the Angular team does not officially support the contents of such a file. [Testing configuration]
Use subpath imports with standard conditions: The build system natively supports production, development, and browser conditions. If your use case can be mapped to these, it may work without customConditions. [Build system migration]
File a bug/feature request: Since this appears to be a gap between @angular/build:application (which supports conditions) and the library test path, this is likely worth reporting to the Angular CLI GitHub repository, as it may be an unimplemented feature or a known limitation.

For authoritative guidance on this specific issue, I'd recommend checking the Angular CLI GitHub issues directly.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

@feral void Kapa.ai is still learning and improving, please let me know how I did by reacting below.

feral void May 23, 2026, 10:15 AM

@rain cave whats then the purpose of providing a buildTarget? To my (very basic understanding) you give @angular/build:unit-test a build target which takes care of building. If that is the case, why does it not behave like executing it standalone aka with ng build. Sure, i can provide a runner config and define some vite settings, but will that affect the build process? And even if it does, i dont think it should

rain caveBOT May 23, 2026, 10:15 AM

Let me check the knowledge base for you again. One moment! :books:

This is a very reasonable question, and unfortunately the knowledge sources do not contain enough detail to give you a definitive answer about the internal mechanics of how buildTarget interacts with @angular/build:unit-test when pointing to @angular/build:ng-packagr.

Here is what the knowledge sources do say about buildTarget:

"Specifies the build target to use for the unit test build in the format project:target[:configuration]. This defaults to the build target of the current project with the development configuration." [CLI test docs]

And regarding the migration from Karma:

"The unit-test builder defaults to "tsConfig": "tsconfig.spec.json" and "buildTarget": "::development". You can explicitly set these options if your project requires different values." [Migrating to Vitest]

So the intent of buildTarget is clearly to delegate the build step to another builder. Your reasoning is sound — if @angular/build:unit-test delegates building to @angular/build:ng-packagr via buildTarget, one would expect it to behave consistently with running that builder standalone (i.e., ng build), including respecting compilerOptions.customConditions.

However, the knowledge sources do not clarify:

Whether @angular/build:unit-test fully delegates all build configuration to the referenced buildTarget, or only partially uses it (e.g., only picking up tsConfig or output paths).
Whether the Vitest/esbuild layer that unit-test introduces on top of the build target overrides or ignores certain TypeScript compiler options like customConditions.
Whether runner-config (a Vitest config file) would affect the build process or only the test execution layer — and based on the docs, it seems scoped to Vitest options, not the underlying build. [Testing configuration]

Your instinct that a `runner-config` / Vitest config should not be the fix for a build-level concern is well-founded. This looks like either a limitation or a bug in how `@angular/build:unit-test` integrates with `@angular/build:ng-packagr`, and I'd strongly recommend opening an issue on the Angular CLI GitHub repository with your reproduction case.