Describe the bug

Right now, this (very thoroughly crafted, nicely done!) ESLint config uses the prefix 'ts/' for typescript-eslint rules per https://github.com/antfu/eslint-config?tab=readme-ov-file#plugins-renaming. That means users configure rules like:

{
  'ts/array-type': 'error',
}

However, the recommended preset configs from typescript-eslint use a '@typescript-eslint/' prefix, not 'ts/'. A lot of projects are accustomed to using the '@typescript-eslint/' prefix. And if folks ever want to combine a typescript-eslint shared config with antfu/eslint-config, they have mismatched prefixes.

It took me a bit of wrestling, but this seems to be working to get those prefixes moved over:

import antfu from "@antfu/eslint-config";

export default antfu()
  .renamePlugins({
    ts: "@typescript-eslint",
  })
  .overrideRules({
    // (example)
    "@typescript-eslint/no-array-constructor": "error",
  });

So, two docs questions:

• Confirmation: is this the right way to do that?
• Do you think it'd be reasonable to mention this anywhere in docs?

Longer-term, I'd be interested in seeing if there's a good way to use typescript-eslint's stricter configs on top of the antfu/eslint-config starter...

Miscellaneous Context

I realize the ts/ prefix is much easier to read+write than the super verbose @typescript-eslint/. But we're stuck with @typescript-eslint/ in typescript-eslint because that's what everyone's been using for years.

We in typescript-eslint have previously surfaced feedback to ESLint core that prefix duplication is a known user pain: eslint/eslint#17766. But there isn't a way to lock down and/or deduplicate the prefixes (yet?).

Reproduction

https://github.com/JoshuaKGoldberg/repros/tree/antfu-eslint-config-typescript-eslint-prefix

System Info

n/a

Used Package Manager

n/a

Validations

• Follow our Code of Conduct
• Read the Contributing Guide.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead.
• The provided reproduction is a minimal reproducible of the bug.

Contributions

• I am willing to submit a PR to fix this issue
• I am willing to submit a PR with failing tests (actually just go ahead and do it, thanks!)