Oct 19, 2023 · Oct 10, 2023 · Oct 17, 2023
diff --git a/docs/linting/troubleshooting/Formatting.mdx b/docs/linting/troubleshooting/Formatting.mdx
 title: What About Formatting?
 ---

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

 ## Formatters vs. Linters

 - any two lint rules can't share config meaning one lint rule's fixer might introduce a violation of another lint rule's fixer (eg one lint rule might use the incorrect indentation character).
 - lint rule fixers can conflict (apply to the same code range), forcing the linter to perform an additional cycle to attempt to apply a fixer to a clean set of code.

 These problems cause a linter to be much slower and, more importantly, much less consistent and less able to handle edge-cases than a purpose-built formatter.
 These problems cause a linter to be much slower - which can be much more of a problem in projects that enable [typed linting](../Typed_Linting.mdx).
 Formatting with a linter is also much less consistent and less able to handle edge-cases than a purpose-built formatter.
 The maintenance cost of formatting-related lint rules is typically very high as a result.

 Modern formatters such as Prettier are architected in a way that applies formatting to all code regardless of original formatting which helps them be more consistent.
 Modern formatters such as Prettier are architected in a way that applies formatting to all code regardless of original formatting.
 This design allows formatters to be much more comprehensive and consistent at much lower maintenance cost than linters.

 ### Suggested Usage - Prettier

 > 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.

 Wesupport the ESLint team's decision and backing logic to move away from _formatting_ and _stylistic_ rules.
 Wemirror the ESLint team's move away from _formatting_ and _stylistic_ rules.
 With the exception of bug fixes, no new formatting- or stylistic-related pull requests will be accepted into typescript-eslint.

 ## `eslint-stylistic`

 The downside of using a comprehensive formatter for formatting is that it will strictly apply opinions to code.
 Although you can [ignore code in Prettier](https://prettier.io/docs/en/ignore.html) and other formatters, including inline such as with [`// prettier-ignore` comments](https://prettier.io/docs/en/ignore.html#javascript), formatters are much more opinionated than lint rules.

 The [`eslint-stylistic`](https://eslint.style) project provides an ESLint plugin containing _formatting_ and _stylistic_ rules.
 That plugin can serve as your formatter if you strongly prefer not to use a dedicated formatter.

 See [ESLint Stylistic > Why?](https://eslint.style/guide/why) for more details on that project's motivation, and [ESLint Stylistic > Getting Started](https://eslint.style/guide/getting-started) for how to set it up.
diff --git a/packages/website/plugins/generated-rule-docs.ts b/packages/website/plugins/generated-rule-docs.ts
      const warningNode = {
        value: `
 <admonition type="warning">
  We strongly recommend you do not use this rule or any other formatting linter rules.
  Use a separate dedicated formatter instead.
  This rule will soon be moved to <a href="https://eslint.style">eslint-stylistic</a>.
  See <a href="/linting/troubleshooting/formatting">What About Formatting?</a> for more information.
 </admonition>
 `,
Original file line number	Diff line number	Diff line change
Expand Up		@@ -3,8 +3,8 @@ id: formatting
		title: What About Formatting?
		---

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

		## Formatters vs. Linters

Expand All		@@ -23,9 +23,12 @@ Additionally linters typically run each rule isolated from one another. This has
		- any two lint rules can't share config meaning one lint rule's fixer might introduce a violation of another lint rule's fixer (eg one lint rule might use the incorrect indentation character).
		- lint rule fixers can conflict (apply to the same code range), forcing the linter to perform an additional cycle to attempt to apply a fixer to a clean set of code.

		These problems cause a linter to be much slower and, more importantly, much less consistent and less able to handle edge-cases than a purpose-built formatter.
		These problems cause a linter to be much slower - which can be much more of a problem in projects that enable [typed linting](../Typed_Linting.mdx).
		Formatting with a linter is also much less consistent and less able to handle edge-cases than a purpose-built formatter.
		The maintenance cost of formatting-related lint rules is typically very high as a result.

		Modern formatters such as Prettier are architected in a way that applies formatting to all code regardless of original formatting which helps them be more consistent.
		Modern formatters such as Prettier are architected in a way that applies formatting to all code regardless of original formatting.
		This design allows formatters to be much more comprehensive and consistent at much lower maintenance cost than linters.

		### Suggested Usage - Prettier

Expand DownExpand Up		@@ -79,5 +82,15 @@ Per [ESLint's 2020 Changes to Rule Policies blog post](https://eslint.org/blog/2
		> 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.

		Wesupport the ESLint team's decision and backing logic to move away from _formatting_ and _stylistic_ rules.
		Wemirror the ESLint team's move away from _formatting_ and _stylistic_ rules.
		With the exception of bug fixes, no new formatting- or stylistic-related pull requests will be accepted into typescript-eslint.

		## `eslint-stylistic`

		The downside of using a comprehensive formatter for formatting is that it will strictly apply opinions to code.
		Although you can [ignore code in Prettier](https://prettier.io/docs/en/ignore.html) and other formatters, including inline such as with [`// prettier-ignore` comments](https://prettier.io/docs/en/ignore.html#javascript), formatters are much more opinionated than lint rules.

		The [`eslint-stylistic`](https://eslint.style) project provides an ESLint plugin containing _formatting_ and _stylistic_ rules.
		That plugin can serve as your formatter if you strongly prefer not to use a dedicated formatter.

		See [ESLint Stylistic > Why?](https://eslint.style/guide/why) for more details on that project's motivation, and [ESLint Stylistic > Getting Started](https://eslint.style/guide/getting-started) for how to set it up.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -92,8 +92,7 @@ export const generatedRuleDocs: Plugin = () => {
		const warningNode = {
		value: `
		<admonition type="warning">
		We strongly recommend you do not use this rule or any other formatting linter rules.
		Use a separate dedicated formatter instead.
		This rule will soon be moved to <a href="https://eslint.style">eslint-stylistic</a>.
		See <a href="/linting/troubleshooting/formatting">What About Formatting?</a> for more information.
		</admonition>
		`,
Expand Down