Overview

Following #8091: we'd like to feature freeze our stylistic rules that work for naming and sorting. Copying much of its description here...

Right now, our Formatting docs reference ESLint's policy on preferring to avoid stylistic rules:

Per ESLint's 2020 Changes to Rule Policies blog post, ESLint itself has moved away from stylistic rules, including formatting rules:

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.

Yet we actively maintain a few rules that arguably fall purely within the prefer-to-avoid area:

• @typescript-eslint/member-ordering: the options are excessively complex, requiring many examples and nested descriptions of options in the docs
• @typescript-eslint/naming-convention: same as member-ordering, and even has FAQs
• @typescript-eslint/sort-type-constituents: supports basic group ordering but is not generally as comprehensive as eslint-plugin-perfectionist

We're going to:

• Feature freeze the aforementioned naming and sorting stylistic rules
  • This would only be a feature freeze - we'd continue to fix bugs in them and update them for new TypeScript versions.
• Explicitly indicate in their docs that further features should be built by the community, with links to any equivalents

Note that this issue does not suggest we want to remove the existing stylistic or stylistic-type-checked presets.

• Rules such as @typescript-eslint/prefer-nullish-coalescing and @typescript-eslint/prefer-string-starts-ends-with are great at helping folks find better ways to write code.
• Even "consistency" rules in there such as @typescript-eslint/array-type that enforce adhering to one of <=3 common syntax forms have a strong benefit in aligning a codebase to a single style. This discussion is about rules that are highly unbounded in complexity and don't have definitive "pick one and practically always use that" solutions within a project.