It is common to encounter statistics framed as exponential functions that highlight the escalating cost of identifying and rectifying software defects.

Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase.

Software Defect Reduction Top 10 List”, Barry Boehm, University of Southern California, Victor R. Basili, University of Maryland

Angular Extended Diagnostics — figure 1

That is why it is essential to reduce the likelihood of introducing new defects at the earliest feasible phase of the development cycle. Fortunately, numerous automated techniques, utilities, and workflows assist in this effort (ranging from IDE-integrated tools, various plugins, auto-formatters, and linters, to constraints imposed during transpilation and compilation, comprehensive static analysis, scanning third-party libraries for known vulnerabilities, and capped by a full-fledged testing pyramid). Certain tools offer support immediately, while others demand extra resources (time spent on configuring the tools correctly, infrastructure to uphold continuous integration, and so on).

Angular version 13.2.0 introduces a new feature known as Extended Diagnostics. This tool is integrated directly into the compilation pipeline for Angular view templates (it is a component of the compiler itself). It requires no additional setup, scripts, or infrastructure to function; it is active by default, including during ng serve when transpiling templates.

Its purpose is to identify potential anomalies that are not strictly errors (they do not trigger compilation failures and they adhere to all syntactic rules) but are nonetheless suspicious and may not reflect the developer's actual intention. It acts as an extra layer of linting specifically for Angular template syntax.

invalidBananaInBox

{ 
  "angularCompilerOptions": {
    "strictTemplates": true,
    "extendedDiagnostics": {
      "checks": {
        "invalidBananaInBox": "error" 
      },
    "defaultCategory": "error"
  }
}

This diagnostic operates under the condition that strictTemplates is enabled. Its purpose is to flag the inverted "banana-in-box" pattern in two-way data binding (indicating the presence of ([...]) instead of the correct [(...)]).

// invalid 
<component ([foo])="bar"></component> 
// valid 
<component [(foo)]="bar"></component>

Although both forms are syntactically valid, the first variant does not establish a two-way binding. Instead, it simply attaches a listener to an event labeled [foo].

nullishCoalescingNotNullable

{ 
  "compilerOptions": { 
    "strictNullChecks": true, 
    "angularCompilerOptions": {
      "strictTemplates": true,
      "extendedDiagnostics": {
        "checks": {
          "nullishCoalescingNotNullable": "error" 
        },
      "defaultCategory": "error"
    }
  }
}

Activating this diagnostic requires both the strictTemplates and strictNullChecks flags to be turned on. It is designed to spot superfluous applications of the nullish coalescing operator ??.

import {Component} from '@angular/core';

@Component({ 
  template: `
    <div>{{ foo ?? 'xxx' }</div> 
    <div>{{ bar ?? 'zzz' }</div>
  `,
  …
})
class MyComponent {
  foo: string | null = 'test'; 
  bar: string = 'test'; 
}

When it comes to the foo property, employing the nullish coalescing operator makes sense (the property has a nullable type). However, with strictTemplates and strictNullChecks enabled, using it on the bar property serves no purpose.

What’s next?

The Angular team intends to introduce new diagnostics in future minor releases of the framework. Since new diagnostics and potential bugs may surface with each version upgrade, any detected anomalies are returned as warnings by default (this behavior can be adjusted using the angularCompilerOptions.extendedDiagnostics.defaultCategory setting found in the tsconfig file). Suggestions for additional diagnostics can be filed through the GitHub feature request process (https://github.com/angular/angular/issues/new?template=2-feature-request.yaml). The complete documentation for Extended Diagnostics is available here: https://angular.io/extended-diagnostics.

References: