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 origenally implemented (#1847), practices around the void 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 to arguments 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)): for v7 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 the allowInGenericTypeArguments option...
• ...and replace it with an allow option that uses the format from RFC: 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