This rule raises an issue when Angular output bindings are given aliases that differ from their property names.

Why is this an issue?

Aliasing output bindings creates unnecessary complexity in your Angular components and directives. When an output property has a different name than its alias, developers must remember both names to use the component correctly.

This dual naming convention increases cognitive load and makes the codebase harder to maintain. It also breaks the principle of least surprise - developers expect the output name to match the property name.

Consistent naming between properties and their public API makes components more predictable and easier to understand, especially for team members who didn’t write the original code.

What is the potential impact?

Aliased outputs can lead to confusion during development and maintenance. Team members may struggle to understand which name to use when binding to the output, leading to bugs and increased development time. The inconsistency also makes code reviews more difficult and reduces overall code quality.

How to fix in Angular?

Remove the alias from the @Output decorator and use the property name directly.

Non-compliant code example

@Component()
class MyComponent {
  @Output('change') valueChange = new EventEmitter(); // Noncompliant
}

Compliant code example

@Component()
class MyComponent {
  @Output() valueChange = new EventEmitter();
}

Remove the alias from the output() function and use the property name directly.

Non-compliant code example

@Component()
class MyComponent {
  valueChange = output({ alias: 'change' }); // Noncompliant
}

Compliant code example

@Component()
class MyComponent {
  valueChange = output();
}

Remove aliases from the outputs metadata array.

Non-compliant code example

@Component({
  outputs: ['valueChange: change'] // Noncompliant
})
class MyComponent {}

Compliant code example

@Component({
  outputs: ['valueChange']
})
class MyComponent {}

Documentation