Thanks to visit codestin.com
Credit goes to github.com

Skip to content

chore(website): add formatting (Prettier) page #5363

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .cspell.json
Original file line number Diff line number Diff line change
Expand Up @@ -59,6 +59,7 @@
"declarators",
"destructure",
"destructured",
"dprint",
"errored",
"erroring",
"ESLint",
Expand Down
34 changes: 34 additions & 0 deletions docs/linting/troubleshooting/FORMATTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
---
id: formatting
title: What About Formatting?
---

We strongly recommend against using ESLint for formatting.
We strongly recommend using [Prettier](https://prettier.io), [dprint](https://dprint.dev), or an equivalent instead.

## Formatters vs. Linters

**Formatters** are tools that verify and correct whitespace issues in code, such as spacing and newlines.
Formatters typically run very quickly because they are only concerned with changing whitespace, not code logic or naming.

**Linters** are tools that verify and correct logical and non-whitespace style issues in code, such as naming consistency and bug detection.
Linters often take seconds or more to run because they apply many logical rules to code.

### Problems with Using Linters as Formatters

Linters apply much more work than formatters -- often including potentially multiple rounds of rule fixers.
That generally makes them run orders of magnitude slower.

Additionally, modern formatters such as Prettier are architected in a way that applies formatting to all code regardless of original formatting.
Linters typically run on a rule-by-rule basis, typically resulting in many edge cases and missed coverage in formatting.

## ESLint Core and Formatting

Per [ESLint's 2020 Changes to Rule Policies blog post](https://eslint.org/blog/2020/05/changes-to-rules-policies#what-are-the-changes):

> Stylistic rules are frozen - we won't be adding any more options to stylistic rules.
> 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.
> Stylistic rules are those related to spacing, conventions, and generally anything that does not highlight an error or a better way to do something.

We support the ESLint team's decision and backing logic to move away from stylistic rules.
With the exception of bug fixes, no new formatting-related pull requests will be accepted into typescript-eslint.
5 changes: 4 additions & 1 deletion packages/website/sidebars/sidebar.base.js
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,10 @@ module.exports = {
type: 'doc',
},
type: 'category',
items: ['linting/troubleshooting/tslint'],
items: [
'linting/troubleshooting/formatting',
'linting/troubleshooting/tslint',
],
},
],
link: {
Expand Down