Docs page(s)

I don't know where this should go. Maybe some kind of "recommendations for plugin integrators" and/or "troubleshooting" page within https://eslint.org/docs/latest/extend/plugins?

What documentation issue do you want to solve?

As seen in #19134 & typescript-eslint/typescript-eslint#10338, some community plugins such as @typescript-eslint/eslint-plugin and eslint-plugin-unicorn rely on implementation details of ESLint core rules. Paraphrased builtinRules usage from typescript-eslint:

import { builtinRules } from 'eslint/use-at-your-own-risk';

const baseRule = builtinRules.get('no-unused-expressions')!;

export default createRule({
  // ...
  create(context, [options]) {
    const rules = baseRule.create(context);

    return {
      ExpressionStatement(node) {
        // ...
        rules.ExpressionStatement(node);
      },
    };
  },
});

I'm told the ESLint team explicitly recommends not doing this practice. There's a reason why it's called "use-at-your-own-risk": these rules are implementation details and should not be relied on.

What do you think is the correct solution?

It'd be lovely to have this noted in docs. Both for visibility and so the plugins can align on a set of preferred strategies. typescript-eslint/typescript-eslint#6456 tracks finding a better way to do things in typescript-eslint.

Participation

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

Additional comments

We should note that the recommendation isn't as simple as "just don't do it!". Many "extension" rules such as @typescript-eslint/class-methods-use-this rely on working the same as ESLint core rules except for specific cases. Plugins at the moment are stuck between a rock, a hard place, and a pit:

• ESLint core won't take in all of the extension behaviors (many wouldn't make sense to propose upstream at all; some were proposed but not accepted)
• Wrapping the base rule is an internal API per this recommendation and not supported
• Copying the rule makes for a much more difficult implementation on the plugin's side

This issue is not to track resolving those difficulties and tradeoffs. I'm just noting it here because the docs page needs to capture the nuance. We in the plugins haven't had a formal recommendation on the right strategy prior to typescript-eslint/typescript-eslint#6456 (comment) - just indications of what not to do.