[eslint-config-recommended]: member-ordering for angular projects

[michaelwittwer]

Currently there is no way to enforce a shared style for member ordering in classes of angular projects. Here is the order I would wish for:

Desired member ordering (Draft)

Order	Member type	Comment
1️⃣	Static properties	Constants, readonly static values
2️⃣	Dependency injected properties (inject())	Fields initialized via inject()
3️⃣	Angular Inputs, Outputs, Queries, Children (input() / output(), ...)	Inputs first, then Outputs
4️⃣	Public properties	Exposed fields (non-decorator, non-injected)
5️⃣	Protected / private properties	Internal state
6️⃣	Constructor (if still used)	(rare in standalone world, but still present sometimes)
7️⃣	Lifecycle hooks	ngOnInit(), ngAfterViewInit(), etc.
8️⃣	Public methods	API surface
9️⃣	Protected methods	Internal helpers
🔟	Private methods	Internal helpers

Rationale:

• Inputs/Outputs first → component interface is immediately visible.
• DI fields together → you clearly see dependencies upfront.
• Public/protected/private members separated → easy to maintain contract.
• Lifecycle hooks together → predictable, easily scannable.
• Public API methods before internal helpers.

Ressources:

• Prefer the inject function over constructor parameter injection (ng-styleguide)
• Group Angular-specific properties before methods (ng-styleguide)
• Use protected on class members that are only used by a component's template (ng-styleguide)
• Use readonly on properties that are initialized by Angular (ng-styleguide)

Considered Options:

• @typescript-eslint/member-order
• sort-class-members/sort-class-members (eslint-plugin-sort-class-members)

The main issue with the considere options, is that we don't have the possibility to differentiate between 2‍⃣ , 3‍⃣ and 5‍⃣ . Naturally we declare injectable properties as private readonly router = inject(Router) which should be treated separate from "normal" private properties.

Additionally ort-class-members/sort-class-members was considered for it't possibility to auto fix the sorting. But with the fixer new issues arise. Reordering fiddles around with new lines, so that in the end blank lines disappear, which help group by modifiers for example.