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 messageArgs
to 76 rules
#6589
Conversation
🦋 Changeset detectedLatest commit: 636cb67 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
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.
@kizu Thank you for creating the PR. I've suggested a performance improvement, but LGTM.
@@ -120,6 +120,7 @@ const rule = (primary, secondaryOptions, context) => { | |||
|
|||
report({ | |||
message: messages.expected(unfixed, fixed), |
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.
[suggest] Performance tip: we can avoid extra evaluations by passing a function instead of a string (as a result of a function call):
message: messages.expected(unfixed, fixed), | |
message: messages.expected, |
The same is true for the other rules.
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.
@ybiquitous Done!
(sidenote: for some reason, I cannot re-request the review from both of you via github UI — it keeps rotating them; first time seeing this behavior — I wonder if this is the intended behavior or a UI bug?)
messageArgs
to xx rules
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.
@kizu Thank you for your pull request.
Returning to this after focusing on the 15.0.0
release.
Let's revert the changes to any of the rules we deprecated in 15.0.0
. It only appears to be a handful of them.
Otherwise, LGTM after making @ybiquitous' suggested changes. Great to see this feature being rolled out across the rules.
.changeset/message-args.md
Outdated
"stylelint": minor | ||
--- | ||
|
||
Added: message arguments to most of the rules that pass them to the built-in 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: message arguments to most of the rules that pass them to the built-in messages | |
Added: `messageArgs` to <number of> rules |
Let's be explicit once we know the number of rules the pull request touches.
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.
@jeddy3 Done! Reverted the changes from the deprecated rules, and updated the changeset with the explicit count (77), also added the mention of the message
option to all the READMEs, as it was reported by the “custom message option” test, did it consistently with the rules that already had it — a paragraph present before the ## Options
header.
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.
@kizu Thank you. LGTM 👍🏼
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.
@kizu Thanks for making the changes.
It's almost there. Before we add these args to our public API will want to ensure they:
- are consistent
- adhere to our latest conventions
Similar to how we approached making some of our reference data public.
I think I've identified 3 inconsistent rules within their respective groups, e.g. *-list
, *-notation
and so on.
We can either:
- make the required changes to bring them inline in this pull request
- remove them from this pull request and tackle them in follow-up ones
Each will require a slight change to rule code and changes to all the testRule
cases.
@@ -75,7 +75,8 @@ const rule = (primary, _secondaryOptions, context) => { | |||
} | |||
|
|||
report({ | |||
message: messages.expected(primary), | |||
message: messages.expected, | |||
messageArgs: [primary], |
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.
messageArgs: [primary], | |
messageArgs: [unfixed, fixed], |
To be aligned with our conventions this should be an "Expected x to be y" message.
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.
Did revert this one — I think changing the message completely is out of scope for this PR, so it is better to handle this one in a follow-up PR.
@@ -55,7 +55,8 @@ const rule = (primary) => { | |||
} | |||
|
|||
report({ | |||
message: messages.expected(propertyName, atRuleName), | |||
message: messages.expected, | |||
messageArgs: [propertyName, atRuleName], |
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.
messageArgs: [propertyName, atRuleName], | |
messageArgs: [atRuleName, propertyName], |
This is the opposite way around compared to the other *-list
rules where the order of the args matches the order in the name, i.e.
at-rule-property-required-list
^ ^
(arg 1) (arg 2)
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.
Did apply this and the next changes, as they did not require any code additions, just change in the order.
@@ -56,7 +56,8 @@ const rule = (primary) => { | |||
|
|||
if (matchesStringOrRegExp(prop, disallowedProperties)) { | |||
report({ | |||
message: messages.rejected(prop, ruleNode.selector), | |||
message: messages.rejected, | |||
messageArgs: [prop, ruleNode.selector], |
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.
messageArgs: [prop, ruleNode.selector], | |
messageArgs: [ruleNode.selector, prop], |
Order is opposite to other *-list
rules. See the other comment.
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.
@kizu Thanks for making the changes and sticking with us.
LGTM, thank you.
Let's create a follow-up issue for the colon notation rule.
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.
@kizu Thanks a lot!
@ybiquitous I notice we can't craft a squashed and rebased commit message when using the merge queue, including suffixing the message with the pull request number. The cleanliness of that approach felt good. Do you know if there's a way to combine merge queue with being able to squash commits and then edit the commit message via the GitHub website? |
Yeah, I notice the inconvenience. And I'm afraid it's not likely to edit the commit message as I know... 😓 |
We can configure the merge queue here. |
I've turned off the merge queue for now. We can turn it back on if GitHub adds a feature to craft the squashed commit message when adding the pull request to the merge queue. |
This may happen soon as it's the most liked feedback item. |
Good news! |
Adds missing
messageArgs
to most rules.messageArgs
: Add experimental support for custom message arguments #6312No, it's self-explanatory.