Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
feat(eslint-plugin): create
no-invalid-void-type
rule (#1847)
- Loading branch information
Showing
7 changed files
with
699 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
101 changes: 101 additions & 0 deletions
101
packages/eslint-plugin/docs/rules/no-invalid-void-type.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,101 @@ | ||
# Disallows usage of `void` type outside of generic or return types (`no-invalid-void-type`) | ||
|
||
Disallows usage of `void` type outside of return types or generic type arguments. | ||
If `void` is used as return type, it shouldn’t be a part of intersection/union type. | ||
|
||
## Rationale | ||
|
||
The `void` type means “nothing” or that a function does not return any value, | ||
in contrast with implicit `undefined` type which means that a function returns a value `undefined`. | ||
So “nothing” cannot be mixed with any other types. If you need this - use the `undefined` type instead. | ||
|
||
## Rule Details | ||
|
||
This rule aims to ensure that the `void` type is only used in valid places. | ||
|
||
The following patterns are considered warnings: | ||
|
||
```ts | ||
type PossibleValues = string | number | void; | ||
type MorePossibleValues = string | ((number & any) | (string | void)); | ||
function logSomething(thing: void) {} | ||
function printArg<T = void>(arg: T) {} | ||
logAndReturn<void>(undefined); | ||
interface Interface { | ||
lambda: () => void; | ||
prop: void; | ||
} | ||
class MyClass { | ||
private readonly propName: void; | ||
} | ||
``` | ||
|
||
The following patterns are not considered warnings: | ||
|
||
```ts | ||
type NoOp = () => void; | ||
function noop(): void {} | ||
let trulyUndefined = void 0; | ||
async function promiseMeSomething(): Promise<void> {} | ||
``` | ||
|
||
### Options | ||
|
||
```ts | ||
interface Options { | ||
allowInGenericTypeArguments?: boolean | string[]; | ||
} | ||
const defaultOptions: Options = { | ||
allowInGenericTypeArguments: true, | ||
}; | ||
``` | ||
|
||
#### `allowInGenericTypeArguments` | ||
|
||
This option lets you control if `void` can be used as a valid value for generic type parameters. | ||
|
||
Alternatively, you can provide an array of strings which whitelist which types may accept `void` as a generic type parameter. | ||
|
||
This option is `true` by default. | ||
|
||
The following patterns are considered warnings with `{ allowInGenericTypeArguments: false }`: | ||
|
||
```ts | ||
logAndReturn<void>(undefined); | ||
let voidPromise: Promise<void> = new Promise<void>(() => {}); | ||
let voidMap: Map<string, void> = new Map<string, void>(); | ||
``` | ||
|
||
The following patterns are considered warnings with `{ allowInGenericTypeArguments: ['Ex.Mx.Tx'] }`: | ||
|
||
```ts | ||
logAndReturn<void>(undefined); | ||
type NotAllowedVoid1 = Mx.Tx<void>; | ||
type NotAllowedVoid2 = Tx<void>; | ||
type NotAllowedVoid3 = Promise<void>; | ||
``` | ||
|
||
The following patterns are not considered warnings with `{ allowInGenericTypeArguments: ['Ex.Mx.Tx'] }`: | ||
|
||
```ts | ||
type AllowedVoid = Ex.MX.Tx<void>; | ||
``` | ||
|
||
## When Not To Use It | ||
|
||
If you don't care about if `void` is used with other types, | ||
or in invalid places, then you don't need this rule. | ||
|
||
## Compatibility | ||
|
||
- TSLint: [invalid-void](https://palantir.github.io/tslint/rules/invalid-void/) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
116 changes: 116 additions & 0 deletions
116
packages/eslint-plugin/src/rules/no-invalid-void-type.ts
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,116 @@ | ||
import { | ||
AST_NODE_TYPES, | ||
TSESTree, | ||
} from '@typescript-eslint/experimental-utils'; | ||
import * as util from '../util'; | ||
|
||
interface Options { | ||
allowInGenericTypeArguments: boolean | string[]; | ||
} | ||
|
||
type MessageIds = | ||
| 'invalidVoidForGeneric' | ||
| 'invalidVoidNotReturnOrGeneric' | ||
| 'invalidVoidNotReturn'; | ||
|
||
export default util.createRule<[Options], MessageIds>({ | ||
name: 'no-invalid-void-type', | ||
meta: { | ||
type: 'problem', | ||
docs: { | ||
description: | ||
'Disallows usage of `void` type outside of generic or return types', | ||
category: 'Best Practices', | ||
recommended: false, | ||
}, | ||
messages: { | ||
invalidVoidForGeneric: | ||
'{{ generic }} may not have void as a type variable', | ||
invalidVoidNotReturnOrGeneric: | ||
'void is only valid as a return type or generic type variable', | ||
invalidVoidNotReturn: 'void is only valid as a return type', | ||
}, | ||
schema: [ | ||
{ | ||
type: 'object', | ||
properties: { | ||
allowInGenericTypeArguments: { | ||
oneOf: [ | ||
{ type: 'boolean' }, | ||
{ | ||
type: 'array', | ||
items: { type: 'string' }, | ||
minLength: 1, | ||
}, | ||
], | ||
}, | ||
}, | ||
additionalProperties: false, | ||
}, | ||
], | ||
}, | ||
defaultOptions: [{ allowInGenericTypeArguments: true }], | ||
create(context, [{ allowInGenericTypeArguments }]) { | ||
const validParents: AST_NODE_TYPES[] = [ | ||
AST_NODE_TYPES.TSTypeAnnotation, // | ||
]; | ||
const invalidGrandParents: AST_NODE_TYPES[] = [ | ||
AST_NODE_TYPES.TSPropertySignature, | ||
AST_NODE_TYPES.CallExpression, | ||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
bradzacher
Member
|
||
AST_NODE_TYPES.ClassProperty, | ||
AST_NODE_TYPES.Identifier, | ||
]; | ||
|
||
if (allowInGenericTypeArguments === true) { | ||
validParents.push(AST_NODE_TYPES.TSTypeParameterInstantiation); | ||
} | ||
|
||
return { | ||
TSVoidKeyword(node: TSESTree.TSVoidKeyword): void { | ||
/* istanbul ignore next */ | ||
if (!node.parent?.parent) { | ||
return; | ||
} | ||
|
||
if ( | ||
validParents.includes(node.parent.type) && | ||
!invalidGrandParents.includes(node.parent.parent.type) | ||
) { | ||
return; | ||
} | ||
|
||
if ( | ||
node.parent.type === AST_NODE_TYPES.TSTypeParameterInstantiation && | ||
node.parent.parent.type === AST_NODE_TYPES.TSTypeReference && | ||
Array.isArray(allowInGenericTypeArguments) | ||
) { | ||
const sourceCode = context.getSourceCode(); | ||
const fullyQualifiedName = sourceCode | ||
.getText(node.parent.parent.typeName) | ||
.replace(/ /gu, ''); | ||
|
||
if ( | ||
!allowInGenericTypeArguments | ||
.map(s => s.replace(/ /gu, '')) | ||
.includes(fullyQualifiedName) | ||
) { | ||
context.report({ | ||
messageId: 'invalidVoidForGeneric', | ||
data: { generic: fullyQualifiedName }, | ||
node, | ||
}); | ||
} | ||
|
||
return; | ||
} | ||
|
||
context.report({ | ||
messageId: allowInGenericTypeArguments | ||
? 'invalidVoidNotReturnOrGeneric' | ||
: 'invalidVoidNotReturn', | ||
node, | ||
}); | ||
}, | ||
}; | ||
}, | ||
}); |
Oops, something went wrong.
Just curious: why does this rule disallow
void
in generic parameters to function calls? Such as the examplelogAndReturn<void>(undefined)
. This makes it difficult to adopt the rule in places where a function's generic parameter ends up as a return type. Like if you havewrapInPromise<T>(fn: () => T): Promise<T>
, thenwrapInPromise<void>()
is disallowed.Would it make sense to change this behavior of the rule by default, or add a configuration option to change it?