Skip to content

Commit 79fbbdf

Browse files
authored
docs: add FAQ about incorrect types (typescript-eslint#8081)
1 parent eff7da1 commit 79fbbdf

File tree

1 file changed

+21
-0
lines changed

1 file changed

+21
-0
lines changed

docs/linting/Troubleshooting.mdx

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -153,6 +153,27 @@ module.exports = {
153153
};
154154
```
155155

156+
## typescript-eslint thinks my variable is never nullish / is `any` / etc., but that is clearly not the case to me
157+
158+
Our type-aware rules almost always trust the type information provided by the TypeScript compiler. Therefore, an easy way to check if our rule is behaving correctly is to inspect the type of the variable in question, such as by hovering over it in your IDE.
159+
160+
If the IDE also shows that the type is never nullish / is `any`, you need to fix the type. A very common case is with the [`no-unnecessary-condition`](/rules/no-unnecessary-condition) rule. Take this code for example:
161+
162+
```ts
163+
let condition = false;
164+
165+
const f = () => (condition = true);
166+
f();
167+
168+
if (condition) {
169+
//^^^^^^^^^ Unnecessary conditional, value is always falsy.
170+
}
171+
```
172+
173+
You can see that the type of `condition` is actually the literal type `false` by hovering over it in your IDE. In this case, typescript-eslint cannot possible know better than TypeScript itself, so you need to fix the report by fixing the type, such as through an assertion (`let condition = false as boolean`).
174+
175+
If the IDE provides different type information from typescript-eslint's report, then make sure that the TypeScript setup used for your IDE, typescript-eslint, and `tsc` are the same: the same TypeScript version, the same type-checking compiler options, and the same files being included in the project. For example, if a type is declared in another file but that file is not included, the type will become `any`, and cause our `no-unsafe-*` rules to report.
176+
156177
## I use a framework (like Vue) that requires custom file extensions, and I get errors like "You should add `parserOptions.extraFileExtensions` to your config"
157178

158179
You can use `parserOptions.extraFileExtensions` to specify an array of non-TypeScript extensions to allow, for example:

0 commit comments

Comments
 (0)