Expose stable machine-readable Angular build diagnostics

Start with the compiler-cli package and the ng build entry point, then trace where Angular compiler and template diagnostics are produced and formatted. Define and document a stable machine-readable output containing the requested diagnostic fields, and verify that a strict-check build can emit it for external baseline tooling.

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 https://github.com/angular/angular/issues/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.