Avoid duplicate plugin registration

[sindresorhus]

It's kinda annoying error. You don't always control the config you import.

---

Fixes #852
Fixes #857

[spence-s]

I think this is a great approach to hoist these.

But 1 callout is that, in our config.ts file, we define the @typescript-eslint plugin for both javascript and typescript configs separately. (ln 47 and ln 384 respectively)

It's been a while, but I am wanting to say I did that for a reason... I am not sure if it matters or not anymore, but I think this will hoist that to the top as well. It honestly may not be a problem at all, but just a call out.

Since all the tests are passing I am not too concerned, but it is something to watch out for.

Another call out is potential for plugins that lint specific non js/ts file types, like a JSON or MD or CSS plugin, would those behave weirdly when hoisted to the top? I am not sure, I have never tried to add those specifically and we filter those out from eslint-config-xo might should add some tests for these cases.

I really like the approach though and think we should try to move forward once we're sure those edge cases will work fine.

[sindresorhus]

Another call out is potential for plugins that lint specific non js/ts file types, like a JSON or MD or CSS plugin, would those behave weirdly when hoisted to the top? I am not sure, I have never tried to add those specifically and we filter those out from eslint-config-xo might should add some tests for these cases.

In ESLint flat config, plugins only register rules (make them available by name). They do not activate them. Rules are activated via rules entries scoped by files globs. So hoisting a JSON plugin to the top is harmless; its rules only fire in configs that have matching file patterns and explicitly enable those rules. I have added a test for this now.