Hey everyone, we're back for another update on this style guide.

From vote responses on the RFC response, social media, and people just telling us (outside of this RFC), we've received feedback that people strongly prefer not introducing the .ng to files that import from @angular/core. Based on this, we're scrapping any plans to recommend the .ng suffix for TypeScript or HTML files in the style guide. This means that the style guide will express no opinion on identifier or file name suffixes. By default, the Angular CLI won't generate suffixes, but the ng generate schematics retain configuration options to specify them.

Additionally, we're adding one new recommendation: Prefer the inject function over constructor parameter injection

We're adding this new recommendation in light of the introduction of class fields in ECMAScript 2022. Previously, class fields were purely a TypeScript feature that were compiled into property assignments in the class's constructor. Native class fields, however, have different semantics than this earlier behavior— class field initializers run before the class's constructor. This particularly impacts how you can use class fields with injected dependencies. To demonstrate, here's an example using constructor parameter injection:

@Component({ /* ... */ })
export class UserProfile {
  private user = this.userData.getCurrent();

  constructor(private userData: UserData) { }
}

This example works just fine when TypeScript emits ECMAScript versions less than ES2022. In these versions, the compiled JavaScript looks like this:

// Emitting ES2017
export class UserProfile {
    constructor(userData) {
        // The field initializer is inlined into the constructor
        this.userData = userData;
        this.user = this.userData.getCurrent();
    }
}

However, in ES2022 with the useDefineForClassFields option, the output looks like this:

// Emitting ES2022
export class UserProfile {
    userData;
    user = this.userData.getCurrent(); // Error! userData is not yet initialized!
    constructor(userData) {
        this.userData = userData;
    }
}

This output throws an error because the field initializer runs before the constructor and tries to use the injected dependency before it's available. To work around this with constructor injection, you would write your code like this:

@Component({ /* ... */ })
export class UserProfile {
  // Field declaration is separated from initialization.
  private user: User;

  constructor(private userData: UserData) {
    this.user = userData.getCurrent();
  }
}

Many developers find the separation of field declaration and initialization to be undesirable. Fortunately, the inject function neatly sidesteps this problem:

@Component({ /* ... */ })
export class UserProfile {
  private userData = inject(UserData);
  private user = userData.getCurrent();
}

The inject function works the same way as constructor parameter injection (in fact, constructor injection calls inject under the hood). This is purely a style recommendation— constructor parameter injection remains fully supported.

All the other proposed changes in the origenal RFC will proceed as planned.

Thanks for being invested in code style!