8000 Rule suggestion: generalize @typescript-eslint/no-angle-bracket-type-assertion · Issue #332 · typescript-eslint/typescript-eslint · GitHub
[go: up one dir, main page]
Skip to content

Rule suggestion: generalize @typescript-eslint/no-angle-bracket-type-assertion #332
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Closed
ThomasdenH opened this issue Mar 5, 2019 · 8 comments · Fixed by #731
Closed

Rule suggestion: generalize @typescript-eslint/no-angle-bracket-type-assertion #332

ThomasdenH opened this issue Mar 5, 2019 · 8 comments · Fixed by #731
Labels
enhancement: plugin rule option New rule option for an existing eslint-plugin rule has pr there is a PR raised to close this package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin

Comments

@ThomasdenH
Copy link
Contributor

I would like to have a more general version of @typescript-eslint/no-angle-bracket-type-assertion, maybe called type-assertion. It would have two options, that can be enabled independently:

no-angle-bracket: If this is enabled, angle bracket type assertions are disallowed.
no-as: If this is enabled, as type assertions are disallowed.

This would allow different use cases. Some people like to use the old assertions instead of the new ones. Personally, I would like to lint all type casting since they introduce unsafety.

The default behaviour would be ['no-angle-bracket'] to match the current situation. If no options are enabled, the lint could warn that the lint can be disabled.
@ThomasdenH ThomasdenH added package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin triage Waiting for team members to take a look labels Mar 5, 2019
@j-f1
Copy link
Contributor
j-f1 commented Mar 5, 2019

How about prefer-as, prefer-angle-bracket, and none as options?

@j-f1 j-f1 added enhancement: plugin rule option New rule option for an existing eslint-plugin rule and removed triage Waiting for team members to take a look labels Mar 5, 2019
@ThomasdenH
Copy link
Contributor Author

Also fine!

The prefer-angle-bracket option is implemented in the tslint-microsoft-contrib ruleset as prefer-type-cast, so adding this option would add another check to the roadmap as well.

@bradzacher
Copy link
Member

The reason I would lean against doing this is because the angle bracket assertions are kind of deprecated, and as is considered best practice because it doesn't clash with jsx syntax (even if you're only writing node code, it's still good to follow best practices).

@ThomasdenH
Copy link
Contributor Author

I personally am mostly interested in the none mode, just thought this would be a nice way to reduce duplication. I'd argue that having all options isn't a lot of extra maintenance cost so for completeness it's worth it. Still, prefer-angle-bracket wouldn't be an option I'd personally use.

@uhyo
Copy link
Contributor
uhyo commented May 10, 2019

I would really love to use "type-assertion": "none" or something like that. It would catch a lot of unsafe code brought into project.

@bradzacher
Copy link
Member
bradzacher commented May 10, 2019 •
edited
Loading

@uhyo, helping your code be more safe can be accomplished via a combination of these 5 rules:

no-unnecessary-type-assertion
ban-ts-ignore
no-explicit-any
no-non-null-assertion
no-inferrable-types

Type assertions are sometimes necessary to help typescript get it right, so banning them all together would (imo) be a terrible idea, as it would cause developers to lose faith in the linting tools.

@uhyo
Copy link
Contributor
uhyo commented May 10, 2019 •
edited
Loading

@bradzacher Thanks for reply. I understand your argument.

IMO, however, a project which gives much weight to safety should use "type-assertion": "none" and require explicit // eslint-disable-next-line: type-assertion on every use of as as well as plenty of comments which describe the necessity of as and how safe it actually is.

@bradzacher bradzacher mentioned this issue May 10, 2019
Closed
14 tasks
@bradzacher
Copy link
Member

I'm not against it being built in (if someone wants to do it), but I would fight hard against it being introduced as a lint rule if I were an engineer on the codebase :)

bradzacher added a commit that referenced this issue Jul 20, 2019
@bradzacher
feat(eslint-plugin): add rule consistent-type-assertions
720b624 
Merges both `no-angle-bracket-type-assertion` and `no-object-literal-type-assertion` into one rule
Fixes #332
Fixes #668
@bradzacher bradzacher mentioned this issue Jul 20, 2019
Merged
@bradzacher bradzacher added the has pr there is a PR raised to close this label Jul 20, 2019
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
enhancement: plugin rule option New rule option for an existing eslint-plugin rule has pr there is a PR raised to close this package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat(eslint-plugin)!: add rule consistent-type-assertions typescript-eslint/typescript-eslint
4 participants
@uhyo @ThomasdenH @bradzacher @j-f1
0