i'm unsure how enforcing of type aliases should work and how to determine need for type alias

whenever possible: where do you think it should be?

whenever possible: where do you think it should be?

All the time, except for this case:

A class cannot implement / extend a type alias that names a union type.

Assuming the above can be detected.

Or better said, I want to use type aliases as long as the compiler permits it.

After spending 5 months working with flow, I've gotten used to writing type statements for everything.
I was thinking that I needed something like this!

The usages part might be hard though because we'd have to track the scope. Doable, but ugly.

Depending on complexity it might just be worth having people use disable comments for the rare cases they use interfaces.

I found this issue while searching for exactly the same thing, although I have a different suggestion.

The no-type-alias is used to define the rules that determine how the type aliases can be implemented in the code: from not allowed at all to only in specific cases like unions and intersections.

On the other hand, the prefer-interface option forces the use of interfaces over type aliases.

I think that the prefer-interface rule is more suitable for this change and would be just a matter of adding the option to select "always" (the default and current behaviour) or "never" (the new option that would force to avoid interfaces).

It wouldn't have any breaking change because the default behaviour would still be the same as we have now, but there would be an option to force the inverse and prefer type aliases over interfaces.

This is something that other rules already have and wouldn't require a lot of different variations to consider like we would have if updating the no-type-alias rule.

+1
I tried to create the PoC for this.
https://github.com/otofu-square/eslint-plugin-prefer-type-alias

@otofu-square - how come you didn't fork this repo and make you changes in your fork?
We're happy to have (and hugely encourage) new contributions!
If you'd worked within this codebase, you'd have had full types for everything (i.e. no anys)!

There isn't a technical limitation for us not yet making the change, it's a manpower issue. There are only a small number of core maintainers.

@bradzacher
Thanks for your comment.
Sounds great.

I'll try to make a PR to this repository.

This was fixed in #463
There is a new rule consistent-type-definitions which lets you choose what type definition style to use