Skip to content

Rule proposal: Prefer VoidFunction #11250

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.

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

Closed
6 tasks done
jakeleventhal opened this issue May 28, 2025 · 3 comments
Closed
6 tasks done

Rule proposal: Prefer VoidFunction #11250

jakeleventhal opened this issue May 28, 2025 · 3 comments
Labels
enhancement: new plugin rule New rule request for eslint-plugin locked due to age Please open a new issue if you'd like to say more. See https://typescript-eslint.io/contributing. package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin wontfix This will not be worked on

Comments

@jakeleventhal
Copy link

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

My proposal is suitable for this project

  • My proposal specifically checks TypeScript syntax, or it proposes a check that requires type information to be accurate.
  • My proposal is not a "formatting rule"; meaning it does not just enforce how code is formatted (whitespace, brace placement, etc).
  • I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Description

Have a --fixable rule that prefers the TS VoidFunction over () => void when defining a type.

Fail Cases

type SomeFunc = () => void;

Pass Cases

type SomeFunc = VoidFunction;

Additional Info

No response

@jakeleventhal jakeleventhal added package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin triage Waiting for team members to take a look enhancement: new plugin rule New rule request for eslint-plugin labels May 28, 2025
@bradzacher
Copy link
Member

Why should you prefer this named type over the literal syntax?
What benefit does it give you?
Why should this be a standard?

Please add some more information justifying why such a rule should exist.

@bradzacher bradzacher added awaiting response Issues waiting for a reply from the OP or another party and removed triage Waiting for team members to take a look labels May 28, 2025
@jakeleventhal
Copy link
Author

I feel like generally this is a better, more clear way to do it. It's just a stylistic preference. I think its more clear and uses a native typescript type. Readability really

There are plenty of other "preference"-based rules so I don't see why this wouldn't be one

@bradzacher
Copy link
Member

Generally now-a-days we don't look to ship rules for stylistic preferences unless there's a really, really good motivating reason a codebase should standardise or if the community is really rallied behind a stylistic decision.

For niche cases like this where it's a purely stylistic personal preference that is also very niche - we don't look to cover it with our plugin.

Instead you can use general purpose rules to ban the undesired code as per this FAQ: https://typescript-eslint.io/troubleshooting/faqs/general#how-can-i-ban-specific-language-feature

@bradzacher bradzacher closed this as not planned Won't fix, can't repro, duplicate, stale May 28, 2025
@bradzacher bradzacher added wontfix This will not be worked on and removed awaiting response Issues waiting for a reply from the OP or another party labels May 28, 2025
@github-actions github-actions bot added the locked due to age Please open a new issue if you'd like to say more. See https://typescript-eslint.io/contributing. label Jun 5, 2025
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 5, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement: new plugin rule New rule request for eslint-plugin locked due to age Please open a new issue if you'd like to say more. See https://typescript-eslint.io/contributing. package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants