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
Chore: enable additional eslint-plugin-jsdoc rules #12336
Conversation
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.
LGTM, thank you!
Could it be worth making a detailed issue with links to the doc blocks missing description and put the help wanted label on it?
Or maybe we can enable the rule with 31 eslint-disable
in order to prevent to increase the comment with missing description.
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.
Looks good, thanks!
Personal preference: require-hyphen-before-param-description to always, but I can live with either, to be honest. |
@ilyavolodin I have no preference either way and am happy to defer to consensus. |
I'm going to go ahead and merge this so as to avoid merge conflicts, but I'm definitely not tied to which style we choose (and would be happy to change it later). |
@mysticatea I like the idea of enabling |
What is the purpose of this pull request? (put an "X" next to item)
[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[x] Other, please explain:
What changes did you make? (Give an overview)
Following up on #12332, this enables two more rules for consistency:
I set both to enforce "never" because that seemed like the more common style within the codebase, but I don't have any personal preferences as to which we pick. I do think it would be good if it was consistent, though, since I believe that would reduce overhead for contributors who don't have much experience with JSDoc.
I think it would also be nice to enable require-description, but there are 31 instances of missing descriptions and I wanted to move onto some more important things. Could it be worth making a detailed issue with links to the doc blocks missing description and put the
help wanted
label on it?Is there anything you'd like reviewers to focus on?
Do others agree that this is something we should do?