-
-
Notifications
You must be signed in to change notification settings - Fork 9
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
feat: add prefer-logical-properties rule #63
Conversation
7df50ab
to
a0ded50
Compare
Thanks for getting this started. There were some edge cases that were discussed in the original issue: Can you describe how you're handling those? |
I don't think we need to have an option to exclude certain properties. Since all properties have roughly the same support by browsers. With the exception of logical units only. What options would you like to see in the rule? |
I think we need a way for people to opt-out on a case-by-case basis. At a minimum, I think we'd need to be able to do this: {
"prefer-logical-properties": ["error", {
allowedProperties: ["padding-left"], // don't warn on these
allowedUnits: ["xyz"] // don't warn on these
}
} |
I've added options |
Thanks, this is looking good. A couple of additional asks:
|
meta: { | ||
type: /** @type {const} */ ("problem"), | ||
|
||
fixable: "code", |
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.
To fix the type error.
fixable: "code", | |
fixable: /** @type {const} */ ("code"), |
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.
Fixed ✅
Renamed the options and added their descriptions to the documentation. |
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.
Just to finish up the docs, we typically include two additional sections:
- When Not to Use It - gives guidance on when it's okay to not use the rule
- Prior Art - links to other tools that do the same thing
Here's an example:
https://github.com/eslint/css/blob/main/docs/rules/no-invalid-properties.md
For prior art, we have:
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 ✅
This is looking good. I just realized that it will also error for @supports (text-align: left) {
/* rules */
} I'm not sure if that's the correct behavior. What do you think? |
Looking good! Two questions... Do we want the rule to also flag the main {
container-type: inline-size;
& h2 {
@container (inline-size > 40em) {
/* .. */
}
} While disallowing this: main {
container-type: inline-size;
& h2 {
@container (width > 40em) {
/* .. */
}
} And do we want to do anything special with |
I think we can skip these for now. If/when other browsers implement the logical equivalent we can revisit.
These aren't properties, so I'm not sure it makes sense to bundle this check in this rule. |
You are right. We should not use linting in I've updated the PR and added new tests. ![]() |
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 for all of your work on this.
(The CI failure is unrelated to this change, so we're not going to worry about that.)
Prerequisites checklist
What is the purpose of this pull request?
Add new rule.
What changes did you make? (Give an overview)
Added new rule for usage logical CSS properties instead of phisical.
Related Issues
#13
Is there anything you'd like reviewers to focus on?
I don't think so.