Deprecate no-type-alias

[JoshuaKGoldberg]

Overview

There are two issues with @typescript-eslint/no-type-alias as it exists today:

• It intersects @typescript-eslint/consistent-type-definitions
• It violates our general ban on rules that exist only to ban specific syntaxes: https://typescript-eslint.io/docs/linting/troubleshooting#how-can-i-ban-specific-language-feature

Proposal: let's deprecate the rule in v6, and remove it in v7?

[bradzacher]

The big question for me to answer when considering whether a rule should be done in user-land with no-restricted-syntax or with a stand-alone rule is really "can we do more than no-restricted-syntax?"

By default no-type-alias really just acts like no-restricted-syntax - it bans all usages of a type alias.
But we do go further by providing options to granularly allow specific type aliases. Now in their most basic form most of the options could be handled with (all be it complex) selectors in no-restricted-syntax, but the in-union style options would be pretty much impossible to do with a pure selector.

---

In terms of intersecting with consistent-type-definitions - there's only a little bit of overlap TBH. CTD specifically only applies to object types - really it should be called consistent-object-type-definitions.

Also no-type-alias should really be thought of a rule which allowlists the types that a codebase should alias - i.e. pushing you to inline types more.

---

I agree that the standard it enforces is of dubious value at best. Should we remove it? It's really hard to say without more information from the community. I don't know if people actually use the rule. This is one of the hardest parts of this project - 99% of our users are silent consumers.

[JoshuaKGoldberg]

Sourcegraph can help inform this!

• ~371 matches for no-type-alias in files that seem to be ESLint configs
• ~213 of those no-type-alias matches are 0|off disables

Looking at other long-standing rules not in preset configs:

• explicit-member-accessibility has ~4.9k results and ~2.1k explicit-member-accessibility disables
• member-ordering has ~29.8k results and ~960 member-ordering disables
• method-signature-style has ~541 results and ~160 method-signature-style disables
• promise-function-async has ~2k results and ~368 promise-function-async disables

_{Queries are inherently slightly inaccurate because of dynamic and multi-line values.}

Given that only ~160 results show up for enabling the rule and it mostly overlaps with with no-restricted-syntax, I'm a good bit more in favor of removing it.

Aside: I kind of want to create a whole dashboard for all rules on Sourcegraph. But that's for another time 😄

[bradzacher]

The thing to look for is eslint-config-standard-with-typescript and eslint-config-airbnb-typescript.

Double check what those configs use and how many people use them.
Most users go down the path of using configs so need to take that into account!

[JoshuaKGoldberg]

Ah good point, thanks!

• eslint-config-airbnb-typescript@17.0.0 does not enable @typescript-eslint/no-type-alias: https://github.com/iamturns/eslint-config-airbnb-typescript/blob/91fd090f6fdd8d598a6ac6e9bb2c2ba33014e425/lib/shared.js
• eslint-config-standard-with-typescript@23.0.0 does not enable @typescript-eslint/no-type-alias: https://github.com/standard/eslint-config-standard-with-typescript/blob/e132c03006cf50f9b77f3c9e506bef9bbf94eebb/src/index.ts

I also tested these with ESLint's --print-config locally.

[JoshuaKGoldberg]

Fixed in #6229. It'll be available in v6. 🚀