Closed FloEdelmann closed 2 months ago
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 :+1: and 5 :heart: 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 :slightly_smiling_face:
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
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'],
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.
Extracted from https://github.com/vuejs/eslint-plugin-vue/issues/2166#issuecomment-2196820750 (by @pauliesnug):
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.