Pelle Wessman

@Primajin Open a new issue for that discussion. Personally I would say: No, it does not make sense :)

My guess is that this is due to ESM / CJS compatibility stuff that differs between the implementations I wonder _where_ that difference is

Perhaps we could eventually add some of the ESLint-Community plugins as well? If so, then of course clearly marking which plugins that are maintained by the `Core` team and which...

It's fixed in https://github.com/neostandard/neostandard

An alternative solution is to use knip for that: https://knip.dev/

I misread the original issue, I thought it was about removing them from package.json. ESLint itself seems to generally dislike autofixing of this rule: https://github.com/typescript-eslint/typescript-eslint/issues/7877 Because they think it's poor...

Happy to help with the experience I got from updating `standard` to ESLint 9 / flat config in [`neostandard`](https://github.com/neostandard/neostandard)

Question to other maintainers: At what point are the path related helpers so large and complex that they merit extraction into a standalone project that focuses on them and just...

Here's a PR that adds this through type generation based on the JSDocs: https://github.com/jsx-eslint/eslint-plugin-react/pull/3830

> I noticed there is no "types" field in package.json - could that be the problem Oh, I forgot to add that? 🫣 Yeah, would be great to add that,...