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: use meta.messages in some rules (1/4) #10764
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.
Thank you for advancing this!
I found a matter to address i18n better.
lib/rules/generator-star-spacing.js
Outdated
const messageId = spaceRequired ? "missing" : "unexpected"; | ||
|
||
// const message = "{{type}} space {{side}} *."; | ||
const data = { side }; |
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'd like to separate message IDs for before
/ after
because languages other than English can't use the word as is.
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, thanks!
Left small nitpicks on the consistent-meta-messages rule.
}, | ||
schema: [], | ||
messages: { | ||
expectedMessages: "expected `meta.messages` property" |
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.
Nit: Could the first word be capitalized (Expected
instead of expected
)?
|
||
create(context) { | ||
return { | ||
AssignmentExpression(node) { |
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.
Nit: This could be simplified using selectors: "AssignmentExpression[left.object.name='module'][left.property.name='exports']"(node) {
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)
Is there anything you'd like reviewers to focus on?
Not all the rules have to be changed in just one PR, I plan to separate it to 3~4 PR. temporally disabled the rule, and will enable it when all the changes finished.