You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The banned type can either be a type name literal (`Foo`), a type name with generic parameter instantiations(s) (`Foo<Bar>`), or the empty object literal (`{}`).
34
+
```ts
35
+
typeOptions= {
36
+
types: {
37
+
[typeName:string]:
38
+
|string
39
+
| {
40
+
message:string;
41
+
fixWith?:string;
42
+
};
43
+
};
44
+
};
45
+
```
46
+
47
+
The rule accepts a single object as options, with the key `types`.
35
48
36
-
```CJSON
49
+
- The keys should match the types you want to ban. The type can either be a type name literal (`Foo`), a type name with generic parameter instantiations(s) (`Foo<Bar>`), or the empty object literal (`{}`).
50
+
- The value can be an object with the following properties:
51
+
-`message: string` - the message to display when the type is matched.
52
+
-`fixWith?: string` - a string to replace the banned type with when the fixer is run. If this is omitted, no fix will be done.
53
+
54
+
### Example config
55
+
56
+
```JSONC
37
57
{
38
58
"@typescript-eslint/ban-types": ["error", {
39
59
"types": {
40
-
// report usages of the type using the default error message
41
-
"Foo": null,
42
-
43
60
// add a custom message to help explain why not to use it
44
-
"Bar": "Don't use bar!",
61
+
"Foo":"Don't use bar!",
45
62
46
63
// add a custom message, AND tell the plugin how to fix it
47
64
"String": {
@@ -58,25 +75,20 @@ The banned type can either be a type name literal (`Foo`), a type name with gene
58
75
}
59
76
```
60
77
61
-
### Example
78
+
### Default Options
62
79
63
-
```json
64
-
{
65
-
"@typescript-eslint/ban-types": [
66
-
"error",
67
-
{
68
-
"types": {
69
-
"Array": null,
70
-
"Object": "Use {} instead",
71
-
"String": {
72
-
"message": "Use string instead",
73
-
"fixWith": "string"
74
-
}
75
-
}
76
-
}
77
-
]
78
-
}
79
-
```
80
+
The default options provides a set of "best practices", intended to provide safety and standardization in your codebase:
81
+
82
+
- Don't use the upper case primitive types, you should use the lower-case types for consistency.
83
+
- Avoid the `Function` type, as it provides little safety for the following reasons:
84
+
- It provides no type-safety when calling the value, which means it's easy to provide the wrong arguments.
85
+
- It accepts class declarations, which will fail when called, as they are called without the `new` keyword.
86
+
- Avoid the `Object` and `{}` types, as they means "any non-nullish value".
87
+
- This is a point of confusion for many developers, who think it means "any object type".
88
+
- Avoid the `object`, as it is currently hard to use due to not being able to assert that keys exist.
89
+
- See [microsoft/TypeScript#21732](https://github.com/microsoft/TypeScript/issues/21732).
90
+
91
+
**_Important note:_** the default options suggests using `Record<string, unknown>`; this was a stylistic decision, as the built-in `Record` type is considered to look cleaner.
0 commit comments