Add TypeScript declarations for configs
FloEdelmann opened this issue ยท 7 comments
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.
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?
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.
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?
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.
@ota-meshi
That PR fixed this issue partially.
Because the types are any it triggers the following linting errors:
20:3 error Unsafe spread of an `any` type @typescript-eslint/no-unsafe-argument
20:16 error Unsafe member access .configs on an `any` value @typescript-eslint/no-unsafe-member-access
using
import tslint from 'typescript-eslint'
import vuePlugin from 'eslint-plugin-vue'
export default tslint.config(
...vuePlugin.configs['flat/recommended'],@ota-meshi That PR fixed this issue partially. Because the types are
anyit triggers the following linting errors:20:3 error Unsafe spread of an `any` type @typescript-eslint/no-unsafe-argument 20:16 error Unsafe member access .configs on an `any` value @typescript-eslint/no-unsafe-member-accessusing
import tslint from 'typescript-eslint' import vuePlugin from 'eslint-plugin-vue' export default tslint.config( ...vuePlugin.configs['flat/recommended'],
- not sure if this is related to "Add TypeScript declarations for configs"
- you could open up a new issue, so others can react and see that there is an open issue
Thank you.
I did a different approach and migrated from eslint-config-prettier and typescript-eslint to @vue/eslint-config-prettier and @vue/eslint-config-typescript to fix this issue.