Agreed, IMO feature parity is a blocker.

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

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.

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

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

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.

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"
  }),
);