Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

JoshuaKGoldberg announced inRFCs
Discussion options

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

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 thanconsistent-type-assertions with itsassertionStyle option set tonever -- this rule will permit type assertions that it considers safe as opposed to blanket banning all type assertions, and
  • this rule is stronger thanconsistent-type-assertions with itsobjectLiteralTypeAssertions option set tonever

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

Fail

typeFoo={readonlybar:number};constfoo={};constfoo2=fooasFoo;foo2.bar.toString();

Pass

typeFoo={readonlybar:number};constfoo={};constfoo2=fooasPartial<Foo>;foo2.bar?.toString();

Additional Info

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

You must be logged in to vote

Replies: 1 comment

Comment options

TBH I really hateconsistent-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 doassertionStyle: 'never' - which causes the rule to ban all assertions. But then you've got no mechanism for enforcing that you use anas 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.

You must be logged in to vote
0 replies
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
RFCs
Labels
package: eslint-pluginIssues related to @typescript-eslint/eslint-plugintriageWaiting for team members to take a lookenhancement: plugin rule optionNew rule option for an existing eslint-plugin rule
2 participants
@JoshuaKGoldberg@bradzacher
Converted from issue

This discussion was converted from issue #5953 on November 17, 2022 15:53.


[8]ページ先頭

©2009-2025 Movatter.jp