Overview

@typescript-eslint/no-invalid-void-type has a couple of surprisingly tricky issues associated with it:

• Bug: [@typescript-eslint/no-invalid-void-type] void is only valid as a return type or generic type argument #6547
• Bug: [@typescript-eslint/no-invalid-void-type] false positive on generics #7227

I think the root issue is that when the rule was originally implemented (#1847), practices around thevoid type were much simpler than they are now(edit: and, as@G-Rath notes, it was largely a port of the even-older TSLint rule!). Conditional types had only been in the language for a couple of years (2.8 release notes). We also hadn't yet solidified our docs and rule options on correctly referring toarguments vs.parameters (#146 ->#5384) and not redundantly referring to them as"a generic" (https://www.totaltypescript.com/no-such-thing-as-a-generic).

Proposal (merging#7227 (comment) &#7227 (comment)): forv7 v8, let's..

• Switch the rule to using type information to determine whether a type argument is passed to a parameter that's eventually used in a return type
• Remove theallowInGenericTypeArguments option...
• ...and replace it with anallow option that uses the format fromRFC: Common format to specify a type or value as a rule option #6017 ->feat(eslint-plugin): [prefer-readonly-parameter-types] added an optional type allowlist #4436

Thoughts, all? cc@bradzacher@auvred@G-Rath@omril1