32eafef6a7
The `undecorated-classes-with-decorated-fields` migration has been introduced with 904a2018e0d3394ad91ffb6472f8271af7845295, but misses logic for decorating derived classes of undecorated classes which use Angular features. Example scenario: ```ts export abstract class MyBaseClass { @Input() someInput = true; } export abstract class BaseClassTwo extends MyBaseClass {} @Component(...) export class MyButton extends BaseClassTwo {} ``` Both abstract classes would need to be migrated. Previously, the migration only added `@Directive()` to `MyBaseClass`, but with this change, it also decorates `BaseClassTwo`. This is necessary because the Angular Compiler requires `BaseClassTwo` to have a directive definition when it flattens the directive metadata for `MyButton` in order to perform type checking. Technically, not decorating `BaseClassTwo` does not break at runtime. We basically want to enforce consistent use of `@Directive` to simplify the mental model. [See the migration guide](https://angular.io/guide/migration-undecorated-classes#migrating-classes-that-use-field-decorators). Fixes #34376. PR Close #35339