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: add internal rule to enforce meta.docs conventions (fixes #6954) #7155
Conversation
@vitorbal, thanks for your PR! By analyzing the annotation information on this pull request, we identified @mysticatea and @kaicataldo to be potential reviewers |
LGTM |
I'd love to see some invalid tests around Require/Enforce/Disallow (not lowercase). Otherwise LGTM! |
Oh, and as a dev team member on ESLint, you can (and probably should) do your work on branches in this repo rather than your fork 😄 |
LGTM |
LGTM, thanks! |
} | ||
|
||
const description = metaDocsDescription.value.value; | ||
const firstWord = description.split(" ")[0]; |
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.
What if the description is
" requires spaces"
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.
@gyandeeps That's a good point, thanks! I pushed a new commit that uses a regular expression to try to get the first word instead of relying on .split()
. I also added some extra tests for that. Let me know what you think!
LGTM |
* @returns {void} | ||
*/ | ||
function checkMetaDocsDescription(context, exportsNode) { | ||
if (!isCorrectExportsFormat(exportsNode)) { |
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.
The function name as it stands now makes it sound like it's actually checking the structure of the exported object. Maybe something like isObjectExpression()
would be better? In fact, any reason why we can't just inline exportsNode.type === "ObjectExpression"
since it's only called once and only does that check?
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.
I think inlining it makes sense here. Thanks for the suggestion!
|
||
const description = metaDocsDescription.value.value; | ||
const matchFirstWord = FIRST_WORD_REGEX.exec(description); | ||
const firstWord = (matchFirstWord && matchFirstWord[1]) ? matchFirstWord[1] : 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.
I wonder if it might be a bit clearer if this line was const firstWord = matchFirstWord !== null ? matchFirstWord[1] : 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.
Good catch, the check for matchFirstWord[1]
is not needed. Thanks! :)
"module.exports = {", | ||
" meta: {", | ||
" docs: {", | ||
" 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.
I don't think this is a blocker, but something to consider - do we want to have an alternate error message if the description field is empty or is just whitespace? Might not be necessary since this is entirely internal and we'll know what this means :)
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.
What if we have two separate messages for:
- description is empty:
'meta.docs.description' must not be empty.
- description starts with a whitespace (should cover "all whitespace" case as well):
meta.docs.description should not start with whitespaces.
That way we can also revert the regex changes and simplify the "firstWord" check to use .split()
again.
What do you think?
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.
I like that - I think those are more helpful error messages!
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.
Added the additional reports. Let me know what you think :)
column: 26 | ||
}] | ||
}, | ||
{ |
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 like this might be a duplicate of the test on line 103
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.
You're right, thanks!
column: 26 | ||
}] | ||
}, | ||
{ |
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.
This could potentially be warned by a separate error if the description is empty or just whitespace.
Yikes - looks like some bugs with the review comments - the last two are showing up on the correct lines in the Conversation view but are in the wrong place in the Files changed view |
LGTM |
if (description.indexOf(" ") === 0) { | ||
context.report({ | ||
node: metaDocsDescription.value, | ||
message: "`meta.docs.description` should not start with whitespaces." |
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.
I think we use whitespace
to refer to both single or multiple whitespace characters in most of our other documentation, so maybe this could be "meta.docs.description should not start with whitespace."
?
ruleTester.run("internal-consistent-docs-description", rule, { | ||
valid: [ | ||
|
||
// wrong exports format: "internal-no-valid-meta" reports this already |
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.
Typo in comment: internal-no-valid-meta
-> internal-no-invalid-meta
"};" | ||
].join("\n"), | ||
|
||
// missing `meta.docs.description` property: "internal-no-valid-meta" reports this already |
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.
Typo in comment: internal-no-valid-meta
-> internal-no-invalid-meta
LGTM |
@kaicataldo sorry for the delay. Thanks again for all the good feedback, I really appreciate it! Just pushed a new commit that fixes the typos you mentioned. |
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, but waiting for today's patch release before merging
Thanks for working on this! |
What is the purpose of this pull request? (put an "X" next to item)
Please check each item to ensure your pull request is ready:
What changes did you make? (Give an overview)
I created a new internal rule to enforce that the
meta.docs.description
property in our core rules follow our conventions of starting with a lowercase character and with one of the following words: "enforce", "disallow", "require". See #6954 for more.Is there anything you'd like reviewers to focus on?