Rule proposal: break up consistent-type-assertions into consistent-type-assertion-syntax and no-unsafe-object-literal-type-assertion about typescript-eslint

[bradzacher]

Funnily there used to be two separate rules.

• no-angle-bracket-type-assertion and
• no-object-literal-type-assertion

In v2 we merged them into one rule
https://github.com/typescript-eslint/typescript-eslint/releases/tag/v2.0.0 // #731

The reason we merged them was because people were asking for a way to completely ban assertion syntax.
Configuring multiple rules around assertions would have been tricky - so we merged them to reduce surface area and confusion.

From my experience in modern TS people don't ever even think of using angle-bracket assertions. So really by-and-large the rule only really enforces the object literal assertions.

---

All that being said - I don't think splitting the rules makes sense.

If someone wants to ban all assertions but also really strongly ban the angle bracket style them this FAQ explains how they can do that - https://typescript-eslint.io/troubleshooting#how-can-i-ban-specific-language-feature

[kirkwaiblinger]

The reason we merged them was because people were asking for a way to completely ban assertion syntax. Configuring multiple rules around assertions would have been tricky - so we merged them to reduce surface area and confusion.

Maybe so... But I, personally, feel very confused by the current setup. Normally when rules have multiple areas that they flag in, it's because they're different instances of the same kind of issue. So I spent a(n) (embarassingly) long time when I was first setting up this rule trying to figure out how object literal type assertions differ based on the syntax used, i.e. why <T>{} might be different from {} as T, in the same way that there is a real difference between, for example, the syntaxes in method-signature-style. But nope! complete red herring. They're just unrelated concerns.

From my experience in modern TS people don't ever even think of using angle-bracket assertions. So really by-and-large the rule only really enforces the object literal assertions.

So far every codebase at my company uses assertionStyle: 'angle-bracket'. Not really sure why but I'm guessing some/all have existed since before as, and/or the devs learned TS back then and never changed habits, so they set that up for consistency and no one has championed getting rid of that kinda-but-not-overtly-deprecated syntax (well, no one but me lol).

If someone wants to ban all assertions but also really strongly ban the angle bracket style them this FAQ explains how they can do that - https://typescript-eslint.io/troubleshooting#how-can-i-ban-specific-language-feature

Sure... but that's a team-member/super-user build-your-own lint rule approach that I could do today, but did not and would not have remotely considered as a user. Plus it obviously doesn't have an autofix, which is a huge appeal in using consistent-type-assertions (i.e. as a codemod tool to migrate to as).

The use case I had/still have is I want to configure different severities for the different parts of this rule. type assertion syntax? error! autofix em! done! object literal type assertions? this is a program logic error, so warn, and people can gradually address them over time if they happen to be looking at the code anyway, but it's nothing to get too stressed about going out of your way to fix.

When I first configured typescript-eslint for my team, I gave up on trying to achieve that, since, at the time, I did not have the knowledge of the existence of no-restricted-syntax or of how to use it. I would just hate for other people in the wild to have the same experience and give up 🤷‍♂️

[bradzacher]

So far every codebase at my company uses assertionStyle: 'angle-bracket'

That is definitely the outlier - most people stopped using angle brackets when as was added because the syntax is much better.

Eg there's barely two dozen hits on sourcegraph for angle bracket vs 10x that for as.

---

Plus it obviously doesn't have an autofix, which is a huge appeal in using consistent-type-assertions (i.e. as a codemod tool to migrate to as).

The rule specifically has an autofixer just for the angle bracket to as case - so you can turn the rule on either as error or warning and you still get the migration power.

I.e. You turn the rule on as a warning (with the setting in as) and no-restricted-syntax on as an error - and you get the best of both worlds.

Though it's worth noting that migrations are not a usecase we consider a priority. Migrations are short-term - usually once-off but linting is forever.

[bradzacher]

The rule purposely hasn't been in the recommended set in a long time (the choice is a stylistic one even if the majority of people follow it).

I'd hazard a guess that many codebases don't even use the rule because it's not in recommended. I do know a few codebases that use .tsx everywhere to make TS ban the angle bracket assertion outright (linters can be disabled but syntax errors cannot)