Add TypeScript declarations for configs

[FloEdelmann]

Extracted from #2166 (comment) (by @pauliesnug):

As for full ESLint v9 support, which is related to the Flat Config milestone, we also need Type Declarations built-into the package so we can use type check configs.

That is not a breaking change and thus does not have to wait for v10.

Note that type declarations are also missing for other parts of the plugin, see #2124.

[ota-meshi]

Hmm... This project is written in JavaScript, so my personal opinion is that I don't want to provide the d.ts files. Because I think it would be difficult to check if the d.ts file is correct in each version.
If eslint-plugin-vue provides d.ts files, I think it would be better to rewrite eslint-plugin-vue in TypeScript. What do you think?

[FloEdelmann]

Because I think it would be difficult to check if the d.ts file is correct in each version.

I don't think this should be an issue. Our configs and external APIs have to conform to a special structure anyway, so this structure can also be defined and documented as a .d.ts file. If we have a mistake there, we can fix it in a patch or minor version, no need to treat types as breaking changes.

Given that more and more users of eslint-plugin-vue and ESLint in general are using TypeScript and are expecting things to just work, there is definitely a need for this. See also the positive reactions to this issue (1 👍 and 5 ❤️ at the time of writing, 3 weeks after opening the issue).

I think it would be better to rewrite eslint-plugin-vue in TypeScript

While I'm positive towards a migration to TypeScript, that is a very big endeavor and nothing that users will benefit from in the near future. So I think this issue shouldn't be blocked by a TypeScript migration. Once the codebase is rewritten in TypeScript, the .d.ts files would be generated automatically, so for users it would look the same.

[ota-meshi]

So I think this issue shouldn't be blocked by a TypeScript migration. Once the codebase is rewritten in TypeScript, the .d.ts files would be generated automatically, so for users it would look the same.

I didn't think it would become a block.
I think people can just submit a PR to @types/eslint-plugin-vue and use the type definitions.

Providing type definitions from eslint-plugin-vue is fine, but I'm not really interested in maintaining it manually.
I personally think it's better to provide it in @types/eslint-plugin-vue if someone is actively intending to maintain it, but is it better to provide type definitions from eslint-plugin-vue?

[FloEdelmann]

is it better to provide type definitions from eslint-plugin-vue

Well, @types/eslint-plugin-vue would be one more package to install, so I guess that providing the type definitions ourselves is better 🙂

Since the type definitions probably won't change much over time, I don't see much value in having them maintained separately in @types/eslint-plugin-vue. I'd prefer having them here under our control. It'd also be less hassle for users to change back to our typing when (in the far future) we have migrated to TypeScript.