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
Copy file name to clipboardExpand all lines: docs/linting/Troubleshooting.mdx
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -243,7 +243,7 @@ See [this issue comment](https://github.com/typescript-eslint/typescript-eslint/
243
243
244
244
### I get `no-unsafe-*` complaints for cross-file changes
245
245
246
-
See [Changes to one file are not reflected in linting other files in my IDE](#changes-to-one-file-are-not-reflected-in-linting-other-files-in-my-ide).
246
+
See [Changes to one file are not reflected in linting other files in my IDE](#changes-to-one-file-are-not-reflected-when-linting-other-files-in-my-ide).
247
247
Rules such as [`no-unsafe-argument`](https://typescript-eslint.io/rules/no-unsafe-argument), [`no-unsafe-assignment`](https://typescript-eslint.io/rules/no-unsafe-assignment), and [`no-unsafe-call`](https://typescript-eslint.io/rules/no-unsafe-call) are often impacted.
Copy file name to clipboardExpand all lines: docs/linting/troubleshooting/Formatting.mdx
+23-13Lines changed: 23 additions & 13 deletions
Original file line number
Diff line number
Diff line change
@@ -6,17 +6,6 @@ title: What About Formatting?
6
6
We strongly recommend against using ESLint for formatting.
7
7
We strongly recommend using [Prettier](https://prettier.io), [dprint](https://dprint.dev), or an equivalent instead.
8
8
9
-
## ESLint Core and Formatting
10
-
11
-
Per [ESLint's 2020 Changes to Rule Policies blog post](https://eslint.org/blog/2020/05/changes-to-rules-policies#what-are-the-changes):
12
-
13
-
> Stylistic rules are frozen - we won't be adding any more options to stylistic rules.
14
-
> We've learned that there's no way to satisfy everyone's personal preferences, and most of the rules already have a lot of difficult-to-understand options.
15
-
> Stylistic rules are those related to spacing, conventions, and generally anything that does not highlight an error or a better way to do something.
16
-
17
-
We support the ESLint team's decision and backing logic to move away from stylistic rules.
18
-
With the exception of bug fixes, no new formatting-related pull requests will be accepted into typescript-eslint.
19
-
20
9
## Formatters vs. Linters
21
10
22
11
**Formatters** are tools that verify and correct whitespace issues in code, such as spacing and newlines.
@@ -40,7 +29,10 @@ Modern formatters such as Prettier are architected in a way that applies formatt
40
29
41
30
### Suggested Usage - Prettier
42
31
43
-
We recommend using [`eslint-config-prettier`](https://github.com/prettier/eslint-config-prettier) to disable formatting rules in your ESLint configuration.
32
+
Neither typescript-eslint nor ESLint core enable any formatting-related rules in any recommended presets.
33
+
However, some third party plugin configurations may still enable that bad practice.
34
+
35
+
If you see formatting rules enabled in your ESLint configuration, we recommend using [`eslint-config-prettier`](https://github.com/prettier/eslint-config-prettier) to disable formatting rules in your ESLint configuration.
44
36
You can then configure your formatter separately from ESLint.
45
37
46
38
Using this config by adding it to the end of your `extends`:
Note that even if you don't use `prettier`, you can use `eslint-config-prettier` as it exclusively turns **off** all formatting rules.
55
+
Note that even if you use a formatter other than `prettier`, you can use `eslint-config-prettier` as it exclusively turns **off** all formatting rules.
56
+
57
+
## ESLint Core and Formatting
58
+
59
+
Most lint rules fall into one of two to three categories:
60
+
61
+
-**Logical**: Rules that care about the logic in runtime behavior of code (such as missing `await`s or invalid logical checks).
62
+
-**Stylistic**: Rules that care about style concerns which do impact runtime behavior of code, but generally not logic. These are mostly around naming or which roughly-equivalent syntax constructs to use (such as function declarations vs. arrow functions).
63
+
-**Formatting**: Stylistic rules that care only about trivia (semicolons, whitespace, etc.) without impacting the runtime behavior of the code. These rules conflict with dedicated formatters such as Prettier.
64
+
65
+
Per [ESLint's 2020 Changes to Rule Policies blog post](https://eslint.org/blog/2020/05/changes-to-rules-policies#what-are-the-changes), ESLint itself has moved away from _stylistic_ rules, including _formatting_ rules:
66
+
67
+
> Stylistic rules are frozen - we won't be adding any more options to stylistic rules.
68
+
> We've learned that there's no way to satisfy everyone's personal preferences, and most of the rules already have a lot of difficult-to-understand options.
69
+
> Stylistic rules are those related to spacing, conventions, and generally anything that does not highlight an error or a better way to do something.
70
+
71
+
We support the ESLint team's decision and backing logic to move away from _formatting_ and _stylistic_ rules.
72
+
With the exception of bug fixes, no new formatting- or stylistic-related pull requests will be accepted into typescript-eslint.
0 commit comments