|
| 1 | +--- |
| 2 | +id: formatting |
| 3 | +title: What About Formatting? |
| 4 | +--- |
| 5 | + |
| 6 | +We strongly recommend against using ESLint for formatting. |
| 7 | +We strongly recommend using [Prettier](https://prettier.io), [dprint](https://dprint.dev), or an equivalent instead. |
| 8 | + |
| 9 | +## Formatters vs. Linters |
| 10 | + |
| 11 | +**Formatters** are tools that verify and correct whitespace issues in code, such as spacing and newlines. |
| 12 | +Formatters typically run very quickly because they are only concerned with changing whitespace, not code logic or naming. |
| 13 | + |
| 14 | +**Linters** are tools that verify and correct logical and non-whitespace style issues in code, such as naming consistency and bug detection. |
| 15 | +Linters often take seconds or more to run because they apply many logical rules to code. |
| 16 | + |
| 17 | +### Problems with Using Linters as Formatters |
| 18 | + |
| 19 | +Linters apply much more work than formatters -- often including potentially multiple rounds of rule fixers. |
| 20 | +That generally makes them run orders of magnitude slower. |
| 21 | + |
| 22 | +Additionally, modern formatters such as Prettier are architected in a way that applies formatting to all code regardless of original formatting. |
| 23 | +Linters typically run on a rule-by-rule basis, typically resulting in many edge cases and missed coverage in formatting. |
| 24 | + |
| 25 | +## ESLint Core and Formatting |
| 26 | + |
| 27 | +Per [ESLint's 2020 Changes to Rule Policies blog post](https://eslint.org/blog/2020/05/changes-to-rules-policies#what-are-the-changes): |
| 28 | + |
| 29 | +> Stylistic rules are frozen - we won't be adding any more options to stylistic rules. |
| 30 | +> 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. |
| 31 | +> Stylistic rules are those related to spacing, conventions, and generally anything that does not highlight an error or a better way to do something. |
| 32 | +
|
| 33 | +We support the ESLint team's decision and backing logic to move away from stylistic rules. |
| 34 | +With the exception of bug fixes, no new formatting-related pull requests will be accepted into typescript-eslint. |
0 commit comments