ESLint version

9.15.0

What problem do you want to solve?

Forking out of #19134 & typescript-eslint/typescript-eslint#10338 -> #19169 (comment):

The only acceptable way to extend a core rule is to copy the file into your own project and then wrap it however you want. That does put more maintenance burden on plugin developers, but that's the point. If you want to do something that isn't officially supported, you need to take full responsibility for that implementation.

This is not an ideal situation for plugin developers. The required extra work in lieu of having a pluggable API or abstractions necessitates that plugin developers:

• Maintain automations to keep up with ESLint's releases - including copying rules and any imported dependencies from ESLint core & its package dependencies
  • Amusingly, this again leads plugins to rely on implementation details. Just, now that would only be during their build steps, not their published packages
• Be deeply familiar with and having a dependency on the potentially any/all implementation details of base rules

Much of that work is already in play today, including taking the dependency on base rules. Both the current unsupported approach and the recommended "copy and wrap" approach cause higher-than-expected levels of implementation detail reliance in extensions.

What do you think is the correct solution?

I honestly have no good idea. If the goal of ESLint is to not allow plugins to rely on any behavior from rules -which is my interpretation of eslint/rfcs#80 (comment) - then generalizing any of the following strategies we typically do in typescript-eslint seem moot.

For example, @typescript-eslint/no-unused-expressions effectively wraps the base rule's ExpressionStatement with filtering logic. But if we can't rely on the base rule having any particular node selectors, then... 🤷

If the ESLint team has appetite to work with plugin developers on this, maybe it would be useful as a next step for someone to gather all the various extension rules and strategies they've taken? Just to see what the landscape & common strategies are?

Participation

• I am willing to submit a pull request for this change.

Additional comments

Personally, I don't think resolving this issue should block #19169. The "don't do this" urge with the current "copy and wrap" recommended approach can be added regardless of this issue. I suspect finding a more preferable strategy (this issue) will take much longer. If and when an alternate strategy is resolved, it can always add it to the docs.

I'll also note that plugins aren't "choosing" to write extension rules: they have to to satisfy user need. For example, typescript-eslint's extension rules must act the same as their base rules except for cases where TypeScript's syntax and/or type checking change something. I see extension rules as an expected use case for plugins that just hasn't yet had a formalized first-party ESLint API. If plugins could avoid taking any dependency on core rule behavior in this way -and therefore inconveniencing the ESLint project- that would be even better!

Edit (March 2025): The discussion is long enough that comments are being hidden by default. Turning the rules from #19173 (comment) into a task list here:

• @typescript-eslint/class-methods-use-this: feat: support TypeScript syntax in class-methods-use-this #19498
• @typescript-eslint/default-param-last: feat: support TypeScript syntax in default-param-last #19431
• @typescript-eslint/init-declarations: feat: support TS syntax in init-declarations #19540
• @typescript-eslint/max-params: feat: support TS syntax in max-params #19557
• @typescript-eslint/no-array-constructor: feat: support TypeScript syntax in no-array-constructor #19493
• @typescript-eslint/no-dupe-class-members: feat: support TS syntax in no-dupe-class-members #19558
• @typescript-eslint/no-empty-function: feat: support TypeScript syntax in no-empty-function rule #19551
• @typescript-eslint/no-invalid-this: feat: support TypeScript syntax in no-invalid-this rule #19532
• @typescript-eslint/no-loop-func: feat: support TS syntax in no-loop-func #19559
• @typescript-eslint/no-loss-of-precision: feat: support TS syntax in no-loss-of-precision #19560
• @typescript-eslint/no-magic-numbers: feat: support TS syntax in no-magic-numbers #19561
• @typescript-eslint/no-redeclare: feat: support TS syntax in no-redeclare #19563
• @typescript-eslint/no-restricted-imports: feat: support TS syntax in no-restricted-imports #19562
• @typescript-eslint/no-shadow: feat: support TS syntax in no-shadow #19565
• @typescript-eslint/no-unused-expressions: feat: support TS syntax in no-unused-expressions #19564
• @typescript-eslint/no-unused-vars: feat: support TypeScript syntax in no-unused-vars #19812
• @typescript-eslint/no-use-before-define: feat: support TypeScript syntax in no-use-before-define #19566
• @typescript-eslint/no-useless-constructor: feat: support TypeScript syntax in no-useless-constructor #19535