Community Feedback: Feature freeze on our naming and sorting stylistic rules

[JoshuaKGoldberg]

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

Updated January 7th, 2024: I'd previously suggested we explicitly remove them from our package. But as @bradzacher pointed out below, there isn't enough active community activity to guarantee the rules will keep up-to-date with the latest TypeScript releases.

Updated proposal: how about we:

• 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

Original proposal kept here for posterity

I propose we move each of those lint rules to their own separate package, with the caveat that whichever package(s) take them on need to keep all of their existing features.

Advantages:

• Those rules' activity won't show up in our activity tracker
• We won't need to work with docs edge cases because of how complicated they are e.g. (COMPLICATED_RULE_OPTIONS)
• There won't be a confusing exemption to us adhering to ESLint's avoidance of new stylistic rules + options
• Each rule would be able to evolve more rapidly by releasing breaking changes outside of the typescript-eslint cadence
• ...what else?

Disadvantages:

• This would add yet another ESLint dependency to impacted projects
• This would make it a bit more work for newer developers to discover and learn these rules
• ...what else?

Thoughts, all?

---

Note that this discussion 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.

[bradzacher]

I don't think that removing our version of a rule in favour of an external one makes sense unless there is feature parity.

For example you mention that sort-type-constituents is not as comprehensive as sort-union-types - but what does that even mean?
None of our options are represented in the other rule, and vice-versa - how do you qualify "comprehensiveness" when they are two disjoint sets?

Additionally whilst sort-union-types supports configuring the ordering style (alphabetical vs length, ascending vs descending) we've never gotten a feature request to configure the style of sorting. So how do you qualify "comprehensiveness" when we have no usecases for the features the other rule offers?

The same goes for member-ordering. It's certainly complex and I hate it - yet users LOVE it. They love being able to super granularly tweak things to completely customise everything to the nth degree and we know that because people consistently keep asking for (and contributing) more. OTOH sort-classes has a tiny fraction of the control that ours has.

How can we push people across to such a rule that likely won't cover their usecase?

[JoshuaKGoldberg]

Agreed, IMO feature parity is a blocker.

[JoshuaKGoldberg]

I updated the OP to suggest we just feature freeze them, rather than deprecate them.

[bradzacher]

In terms of separating these out into a new, separate package entirely (i.e. eslint-plugin-rules-from-typescript-eslint-that-were-exiled) - I don't agree that this is a good approach.

I don't believe that us washing our hands of them by moving them to an unowned / unmaintained 3rd-party package benefits anyone. At least living within our repo we can easily and will ensure they at least keep working forever as new TS features release.

I'd be more than happy for us to add a big banner to each rule that says "these rules are feature frozen - we will fix bugs and support new TS features, but will not accept new feature requests" - i.e. the same stance as ESLint core has for its stylistic rules and would prefer that to shunting them out to a new repo.

[JoshuaKGoldberg]

big banner to each rule that says "these rules are feature frozen ..."

That would satisfy what I'm aiming for, I think 🙂 - reducing maintenance cost & messaging discrepencies.

[JoshuaKGoldberg]

I updated the OP to suggest we just feature freeze them, rather than deprecate them.

[JoshuaKGoldberg]

@bradzacher I just had an epiphany while chatting with @43081j about whether eslint-plugin-package-json should include -> eslint-plugin-clutter areas of things.

My instinct for ESLint rules is that they should approximately never have significantly more nuance & overhead than the plugin they're contained in. At that point they probably deserve their own plugin. This is because users want to have nice preset configs that speak to their general needs - and as soon as you have even one rule that deserves its own presets, it's not really practical to have the more general containing plugin provide that.

For us: https://typescript-eslint.io/rules/naming-convention could provide presets for popular coding styles and/or more opinionated settings... but since it's part of typescript-eslint as a whole, we'd need to either bake preset options in the rule a la ban-types > extendDefaults (eww) or provide top-level shareable configs containing it (eww).

That train of thought has re-invigorated me into thinking about this discussion.

[bradzacher]

One of the benefits of ESLint is that anyone can build shared configs on top of any other plugin.
There's no restriction to prevent 3rd parties from creating these presets for a specific rule.
But it's just not something we see in the ecosystem.

For something like naming convention it likely hasn't happened because it's so opinionated - there aren't really enough standards amongst the JS community and ultimately most people are covered by the rule's defaults of camel case.

For ban types you'd have the same problem with our without a 3rd party config. People would want to customise things you need some mechanism to allow people to build on top. To be fair - extendDefaults is an answer to a legacy config problem. In legacy configs people don't import from your package - so providing, say, a utility function to allow them to compose things wasn't a done thing -- you needed to provide an in-config way of doing it.

With flat configs people are importing typescript-eslint so doing things like exporting tsesling.helpers.banType.defaults is now a viable alternative to fuckery. We could also provide some defaults for naming-convention that way too.

It's actually not a bad idea to do that, TBH. We could export some defaults for naming-convention and the defaults for ban-types. We could also export some common setups for no-restricted-syntax that way.

[JoshuaKGoldberg]

Just ideating, we could even make the provided JS configs functions (that still happen to have the expected properties when not called)... then folks could call them to pass in common preferences or overrides.

export default tseslint.config(
  // ...
  ...tseslint.configs.stylisticTypeChecked({
    "consistent-type-definitions": "type"
  }),
);

[JoshuaKGoldberg]

I sent a few pings around and nobody had more things to add to the discussion. Filed #8792 to track doing it. Thanks all! 💙