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

Add messageArgs to 76 rules #6589

Merged
merged 8 commits into from Feb 14, 2023
Merged

Add messageArgs to 76 rules #6589

merged 8 commits into from Feb 14, 2023

Conversation

kizu
Copy link
Member

@kizu kizu commented Jan 24, 2023

Adds missing messageArgs to most rules.

Which issue, if any, is this issue related to?

Is there anything in the PR that needs further explanation?

No, it's self-explanatory.

@changeset-bot
Copy link

changeset-bot bot commented Jan 24, 2023

🦋 Changeset detected

Latest commit: 636cb67

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
stylelint Minor

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

Copy link
Member

@ybiquitous ybiquitous left a 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),
Copy link
Member

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

Suggested change
message: messages.expected(unfixed, fixed),
message: messages.expected,

The same is true for the other rules.

Copy link
Member Author

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

@jeddy3 jeddy3 changed the title Add messageArgs to most rules that use them Add messageArgs to xx rules Feb 10, 2023
Copy link
Member

@jeddy3 jeddy3 left a 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.

"stylelint": minor
---

Added: message arguments to most of the rules that pass them to the built-in messages
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Copy link
Member Author

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.

@kizu kizu requested review from jeddy3 and ybiquitous and removed request for jeddy3 and ybiquitous February 11, 2023 23:14
@kizu kizu changed the title Add messageArgs to xx rules Add messageArgs to 77 rules Feb 11, 2023
Copy link
Member

@ybiquitous ybiquitous left a 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 👍🏼

Copy link
Member

@jeddy3 jeddy3 left a 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:

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
messageArgs: [primary],
messageArgs: [unfixed, fixed],

To be aligned with our conventions this should be an "Expected x to be y" message.

Copy link
Member Author

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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)

Copy link
Member Author

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
messageArgs: [prop, ruleNode.selector],
messageArgs: [ruleNode.selector, prop],

Order is opposite to other *-list rules. See the other comment.

@kizu kizu changed the title Add messageArgs to 77 rules Add messageArgs to 76 rules Feb 13, 2023
@kizu kizu requested a review from jeddy3 February 13, 2023 13:10
Copy link
Member

@jeddy3 jeddy3 left a 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.

Copy link
Member

@ybiquitous ybiquitous left a 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!

@jeddy3
Copy link
Member

jeddy3 commented Feb 13, 2023

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

@ybiquitous
Copy link
Member

Yeah, I notice the inconvenience. And I'm afraid it's not likely to edit the commit message as I know... 😓

@ybiquitous
Copy link
Member

We can configure the merge queue here.

@jeddy3
Copy link
Member

jeddy3 commented Feb 14, 2023

Yeah, I notice the inconvenience. And I'm afraid it's not likely to edit the commit message as I know...

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.

@jeddy3 jeddy3 merged commit bc55fa1 into stylelint:main Feb 14, 2023
@jeddy3
Copy link
Member

jeddy3 commented Feb 14, 2023

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.

@kizu kizu deleted the message-args branch February 14, 2023 11:50
@ybiquitous
Copy link
Member

This may happen soon as it's the most liked feedback item.

Good news!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants