New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add more precise types in the JSDoc #818
base: main
Are you sure you want to change the base?
Conversation
The failing tests seem unrelated to my PR. I'm changing only comments |
hmm, looks like the jsdoc parser of eslint does not like the object types defining properties. And given that the @Lyrkan @weaverryan should we disable that rule ? |
Or maybe we should migrate to https://github.com/gajus/eslint-plugin-jsdoc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for not looking at this sooner, those are some great changes :)
@Lyrkan @weaverryan should we disable that rule ?
Or maybe we should migrate to gajus/eslint-plugin-jsdoc
We could try gajus/eslint-plugin-jsdoc
but I wouldn't mind disabling valid-jsdoc
entirely either tbh.
My preference would be to remove our |
@Lyrkan @weaverryan I made the migration to eslint-plugin-jsdoc (and I fixed all the extra things it reports, which were not detected by |
The failure for the job |
This documents the value type for arrays of strings in arguments.
webpack provides type definitions for their whole API, so we can reference their type rather than specifying a generic "object" type. Referencing the webpack types was already done for the returned configuration.
Most of them are documented as receiving an object and returning an object or void. But some callbacks dealing with parts of the webpack configuration itself have a more precise type for the options object.
This documents that they are used in such a way, with the type of the values.
This brings the list of supported options in the type definitions with their type, which lets IDEs provide autocompletion for them.
The deprecated valid-jsdoc rule of eslint does not support using typescript syntax for types, while it allows being more precise about types in a much more readable way than using the older jsdoc syntax with separate typedef or callback definitions. The plugin also implements more rules than what valid-jsdoc does.
These are the type improvements coming from my investigation in #816 (and then pushed until the end rather than stopping at a few methods for the experiment)