Enhancement: [consistent-type-assertion] Bring in options from total-functions/no-unsafe-type-assertion

[JoshuaKGoldberg]

Before You File a Proposal Please Confirm You Have Done The Following...

• I have searched for related issues and found none that match my proposal.
• I have searched the current rule list and found no rules that match my proposal.
• I have read the FAQ and my problem is not listed.

My proposal is suitable for this project

• I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Link to the rule's documentation

https://typescript-eslint.io/rules/consistent-type-assertions

Description

https://github.com/danielnixon/eslint-plugin-total-functions#total-functionsno-unsafe-type-assertion has some useful options:

• this rule is weaker than consistent-type-assertions with its assertionStyle option set to never -- this rule will permit type assertions that it considers safe as opposed to blanket banning all type assertions, and
• this rule is stronger than consistent-type-assertions with its objectLiteralTypeAssertions option set to never

Can we add these options to @typescript-eslint/consistent-type-assertions?

Fail

type Foo = { readonly bar: number };
const foo = {};
const foo2 = foo as Foo;
foo2.bar.toString();

Pass

type Foo = { readonly bar: number };
const foo = {};
const foo2 = foo as Partial<Foo>;
foo2.bar?.toString();

Additional Info

Forking conversation out from danielnixon/eslint-plugin-total-functions#665.

[bradzacher]

TBH I really hate consistent-type-assertions.
A while back we merged a few rules together and I think that the UX suffered because of it.

One big problem is that you can do assertionStyle: 'never' - which causes the rule to ban all assertions. But then you've got no mechanism for enforcing that you use an as over an angle bracket assertion - which is obv a problem. A lot of users complained.

I think we need to take a look at this rule and really evaluate the point of it and what we might do better.