Expose stable machine-readable Angular build diagnostics

[OmerGronich]

Which @angular/* package(s) are relevant/related to the feature request?

compiler-cli

Description

Large Angular codebases often want to enable stricter compiler checks, especially strictTemplates and extended diagnostics, but cannot fix all existing diagnostics in one migration.

Angular already supports category-based strictness ratcheting through template type-checking flags. That helps when a whole category of checks is too noisy.

It does not solve the case where a team wants a check enabled, but wants to treat existing diagnostics as migration debt while preventing new diagnostics from being introduced.

Teams can build this externally by parsing ng build output, but text output is not a stable API. Angular diagnostics can include template source spans and compiler-specific formatting, which makes external parsing fragile.

This is not a request for strictTemplates warning mode. A previous discussion in angular/angular#55868 explained why warning mode is not a good fit for strictTemplates, especially because template type-checking often produces TypeScript diagnostics from generated template-checking code.

This request is only about exposing stable diagnostic output so external tooling can implement baseline/ratchet workflows reliably.

Proposed solution

Expose stable machine-readable diagnostics from Angular CLI builds.

For example:

ng build my-app --configuration strict-check --diagnostics-format json

or:

ng build my-app --configuration strict-check --diagnostics-output angular-diagnostics.json

The exact CLI/API shape is not important. The important part is that ng build can emit stable, machine-readable diagnostics.

Example shape:

{
  "diagnostics": [
    {
      "code": "NG8002",
      "category": "error",
      "source": "angular-template",
      "message": "Can't bind to ...",
      "file": "libs/example/src/example.component.html",
      "startLine": 12,
      "startColumn": 7,
      "endLine": 12,
      "endColumn": 28,
      "relatedInformation": []
    }
  ]
}

The schema should include enough stable information for tools to compare diagnostics across runs, such as diagnostic code, category/severity, source, file, source span, message, and related information when available.

This would enable external workflows like:

ng build my-app --configuration strict-check --diagnostics-output angular-diagnostics.json
angular-baseline check angular-diagnostics.json

That allows teams to create a migration ratchet:

• Existing diagnostics are treated as migration debt.
• New diagnostics fail CI.
• Fixed diagnostics can be removed from the baseline.
• The codebase becomes stricter over time.

This is similar in spirit to tsc-baseline or ESLint bulk suppressions, but for Angular compiler and template diagnostics.

Alternatives considered

Use existing template strictness flags

Angular's existing strictness flags are useful for category-based rollout.

However, disabling a category allows both existing and new violations in that category.

A diagnostic baseline lets a team keep the check enabled while allowing only known existing diagnostics.

Parse ng build text output

Teams can parse ng build output today, but this is fragile because CLI text output is optimized for humans, not long-term machine consumption.

Add first-class Angular diagnostic baselines

Angular could provide a full diagnostic baseline feature directly, for example:

ng build my-app --configuration strict-check --update-diagnostic-baseline
ng build my-app --configuration strict-check --diagnostic-baseline angular-diagnostics.baseline.json

That would be useful, but stable machine-readable diagnostics would already allow the ecosystem to build this externally.

[tomer953]

Yes, I opened the mentioned issue, and few years later:

1. We are still don't have strictTemplates in our code base
2. The actual number of errors in our codebase almost doubled since then

Currently its all or nothing, no middle. If we want to block new errors we first need to fix the existing.

A tool like in the proposal, can opens a door to block new errors in large monorepo, for example count the total errors in the ci and validate no new errors.

[JeanMeche]

Would in your case a migration that adds $any() on every failure be a solution toward enabling strictTemplate ?

[tomer953]

Not for our repo.

some checks are still made without strictTemplates flag, ie checking input binding.
Those binding can throw error if you turn on the flag duo to null/undefined strict type checking.
if we will migrate the binding to use $any, we basically give up on the entire type checking and not only on the "strictness" part of that check.
And we talk about thousands of errors.

We need a way to:

1. Block new errors
2. Being able to fix existing in incremental process

Maybe adding a flag to the build process to emit the full diagnostics can be a good idea.

[OmerGronich]

Would in your case a migration that adds $any() on every failure be a solution toward enabling strictTemplate ?

I don’t think an automatic $any() migration solves the same problem for us.

$any() is a source-code suppression, we need a CI/build ratchet. Adding $any() in thousands of places would make strictTemplates pass, but it would also weaken checking at those binding sites because the expression becomes any. That is broader than recording “this diagnostic already exists” and failing only on new diagnostics.

It would also put the migration debt directly into application templates. In our codebase, we want $any() to remain an explicit escape hatch, not become the default pattern that humans and AI agents copy from existing code.

Our goal is to keep stricter checks enabled, block new diagnostics, and gradually burn down existing debt. This is similar to ESLint bulk suppressions, where existing violations are recorded externally while the rule still applies to new code.

So the primitive we need is stable machine-readable diagnostics, not necessarily first-class Angular baselines. Even an output file containing diagnostic code, category, source, file/span, message, and related information would let teams build baseline/ratchet tooling externally.