Feature: Generate typings for rules etc.

[pauliesnug]

Currently we package with Babel to pure JS, but it would be awesome if we could include some .d.ts files with the official build for programmatic, auto-completion, and extension use. This shouldn't be too difficult considering it's already written in TypeScript.

[G-Rath]

Can you provide some real-world examples of where the types would actually be used? (beyond that someone could "one day" want to extend a rule, since I don't think anyone is doing that currently with our rules) My understanding is that ESLint tooling is still not in a good position to properly utilize typings for rules and that that doesn't change with the new flat config format.

The downsides with shipping types is that they add a bit to the package size and increase the surface area of our build infrastructure since Babel doesn't support generating types - neither are particularly costly but relative to not having an actual common real world usecase they're pretty expensive...

[pauliesnug]

Can you provide some real-world examples of where the types would actually be used? (beyond that someone could "one day" want to extend a rule, since I don't think anyone is doing that currently with our rules) My understanding is that ESLint tooling is still not in a good position to properly utilize typings for rules and that that doesn't change with the new flat config format.

@G-Rath Sure! For this issue to be sparked, I was trying to implement a way to use eslint-plugin-jest with eslint-define-config which is a really awesome strongly-typed way to configure multiple ESLint plugins in a modular way. All of this is to say that without TypeScript types it's impossible to use the features of TypeScript and in some cases impossible to even use the plugin in the first place. Even just an interface with the structure of:

export interface RuleOptions {
       /**
        * this is an example of a description for the rule.
        * 
        * @see [rule-name](https://docs.example.com/rule-name.md)
        */
      'jest/rule-name': string;
}

would make all the difference. This would produce a much lesser impact. Alternatively, types could be provided in a separate package if bundle size is a concern.

[SimenB]

I think it would be fine to ship types. We already run tsc, so it'd just be a quick config change to have it emit definition files. Are we certain the generated types helps with eslint-define-config? Seems to me like we need custom code to work with them (https://github.com/eslint-types/eslint-define-config/blob/main/README.md#want-to-support-your-own-plugin), which I don't think we should add (but happy to ship our types if that helps to create your own)

I don't really care about bundle size, but we could also bundle up the types into a single file like we do in Jest (via https://www.npmjs.com/package/@microsoft/api-extractor) in order to minimise the impact

[Logicer16]

that doesn't change with the new flat config format

As the new flat config format requires users to import plugins and their configs themselves, plugins can now be type checked within the config. This is the extra level of support for flat configs currently being tracked within eslint/eslint#18093.

[dmurvihill]

+1 on this, I'm getting a linter warning in eslint.config.js when typed linting is enabled.

[SimenB]

Happy to take a PR! I don't care particularly about some other plugin (although it would be cool to support if the maintenance burden was low/non-existent), but not being annoying to people with // @ts-check from https://typescript-eslint.io/getting-started/ is certainly worth it 👍