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

feat: add prefer-logical-properties rule #63

Merged
merged 8 commits into from
Mar 3, 2025

Conversation

azat-io
Copy link
Contributor

@azat-io azat-io commented Feb 22, 2025

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.

@azat-io azat-io force-pushed the feat/prefer-logical-properties branch from 7df50ab to a0ded50 Compare February 22, 2025 15:18
@nzakas
Copy link
Member

nzakas commented Feb 24, 2025

Thanks for getting this started. There were some edge cases that were discussed in the original issue:

#13 (comment)
#13 (comment)

Can you describe how you're handling those?

@azat-io
Copy link
Contributor Author

azat-io commented Feb 24, 2025

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?

@nzakas
Copy link
Member

nzakas commented Feb 25, 2025

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
    }
}

@azat-io
Copy link
Contributor Author

azat-io commented Feb 26, 2025

I've added options allowedUnits and allowedProperties ✅.

@nzakas
Copy link
Member

nzakas commented Feb 26, 2025

Thanks, this is looking good. A couple of additional asks:

  1. Can you changed allowedProperties to allowProperties and allowedUnits to allowUnits? I just went through and checked which convention we are using in other rules and it's "allow" rather than "allowed".
  2. Can you also update the docs to mention the new options?

meta: {
type: /** @type {const} */ ("problem"),

fixable: "code",
Copy link
Member

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.

Suggested change
fixable: "code",
fixable: /** @type {const} */ ("code"),

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed ✅

@azat-io
Copy link
Contributor Author

azat-io commented Feb 26, 2025

Renamed the options and added their descriptions to the documentation.

Copy link
Member

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:

  1. When Not to Use It - gives guidance on when it's okay to not use the rule
  2. 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:

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added ✅

@nzakas
Copy link
Member

nzakas commented Feb 26, 2025

This is looking good. I just realized that it will also error for @supports rules, such as:

@supports (text-align: left) {
    /* rules */
}

I'm not sure if that's the correct behavior. What do you think?

@jeddy3
Copy link

jeddy3 commented Feb 27, 2025

Looking good! Two questions...

Do we want the rule to also flag the width and height size features (useful for alignment with the container type)?, i.e. allow this:

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 overflow-x and overflow-y as their logical counterparts are only supported by Firefox?

@nzakas
Copy link
Member

nzakas commented Feb 27, 2025

And do we want to do anything special with overflow-x and overflow-y as their logical counterparts are only supported by Firefox?

I think we can skip these for now. If/when other browsers implement the logical equivalent we can revisit.

Do we want the rule to also flag the width and height size features (useful for alignment with the container type)?,

These aren't properties, so I'm not sure it makes sense to bundle this check in this rule.

@azat-io
Copy link
Contributor Author

azat-io commented Mar 1, 2025

This is looking good. I just realized that it will also error for @supports rules

You are right. We should not use linting in @supports directives. Stylelint's rules don't do that either.

I've updated the PR and added new tests.

image

Copy link
Member

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

@nzakas nzakas merged commit 2a440ce into eslint:main Mar 3, 2025
21 of 22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Complete
Development

Successfully merging this pull request may close these issues.

3 participants