Skip to content
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

Merged
merged 5 commits into from Sep 27, 2016

Conversation

vitorbal
Copy link
Member

What is the purpose of this pull request? (put an "X" next to item)

[x] Other, please explain:
Chore. Add a new internal rule to enforce meta.docs.description conventions. 

Please check each item to ensure your pull request is ready:

  • I've read the pull request guide
  • I've included tests for my change
  • I've updated documentation for my change (if appropriate)

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?

  • is the name of the rule okay?
  • any more test cases that you can think of?

@mention-bot
Copy link

@vitorbal, thanks for your PR! By analyzing the annotation information on this pull request, we identified @mysticatea and @kaicataldo to be potential reviewers

@eslintbot
Copy link

LGTM

@platinumazure
Copy link
Member

platinumazure commented Sep 14, 2016

I'd love to see some invalid tests around Require/Enforce/Disallow (not lowercase). Otherwise LGTM!

@platinumazure
Copy link
Member

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 😄

@eslintbot
Copy link

LGTM

@platinumazure
Copy link
Member

LGTM, thanks!

}

const description = metaDocsDescription.value.value;
const firstWord = description.split(" ")[0];
Copy link
Member

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"

Copy link
Member Author

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!

@eslintbot
Copy link

LGTM

* @returns {void}
*/
function checkMetaDocsDescription(context, exportsNode) {
if (!isCorrectExportsFormat(exportsNode)) {
Copy link
Member

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?

Copy link
Member Author

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;
Copy link
Member

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;

Copy link
Member Author

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: ''",
Copy link
Member

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 :)

Copy link
Member Author

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?

Copy link
Member

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!

Copy link
Member Author

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
}]
},
{
Copy link
Member

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

Copy link
Member Author

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
}]
},
{
Copy link
Member

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.

@kaicataldo
Copy link
Member

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

@vitorbal vitorbal added the accepted There is consensus among the team that this change meets the criteria for inclusion label Sep 19, 2016
@eslintbot
Copy link

LGTM

if (description.indexOf(" ") === 0) {
context.report({
node: metaDocsDescription.value,
message: "`meta.docs.description` should not start with whitespaces."
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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

@eslintbot
Copy link

LGTM

@vitorbal
Copy link
Member Author

@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.

Copy link
Member

@kaicataldo kaicataldo left a 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

@kaicataldo kaicataldo merged commit 7bb800d into eslint:master Sep 27, 2016
@kaicataldo
Copy link
Member

Thanks for working on this!

@vitorbal vitorbal deleted the metadata_internal_rule branch September 27, 2016 15:41
@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators Feb 6, 2018
@eslint-deprecated eslint-deprecated bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Feb 6, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants