This rule raises an issue when Angular input properties are given different names (aliases) than their actual property names.

Why is this an issue?

Aliasing input bindings creates confusion between the template usage and the component implementation. When an input property has a different name in templates than in the component class, it becomes harder for developers to understand the relationship between the two.

This inconsistency makes code maintenance more difficult, especially when multiple developers work on the same codebase. It also breaks the principle of least surprise, where developers expect the template binding name to match the property name.

The practice can lead to debugging difficulties when developers search for property usage but cannot find template references due to the name mismatch.

What is the potential impact?

Code becomes harder to understand and maintain. Developers may struggle to trace the connection between template bindings and component properties, leading to increased development time and potential bugs during refactoring.

How to fix in Angular?

Remove the alias and use the property name directly in both the component and template. This creates a clear, consistent naming convention.

Non-compliant code example

@Component({})
class MyComponent {
  @Input('userName') name: string; // Noncompliant
}

Compliant code example

@Component({})
class MyComponent {
  @Input() userName: string;
}

For the new input() function, remove the alias option and use the property name directly.

Non-compliant code example

@Component({})
class MyComponent {
  name = input('', { alias: 'userName' }); // Noncompliant
}

Compliant code example

@Component({})
class MyComponent {
  userName = input('');
}

In the inputs array, use the property name without aliasing syntax.

Non-compliant code example

@Component({
  inputs: ['name: userName'] // Noncompliant
})
class MyComponent {}

Compliant code example

@Component({
  inputs: ['userName']
})
class MyComponent {}

Documentation