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 a lint for dangerous parent selector use in mixins #892

Closed
nex3 opened this issue Dec 6, 2023 · 2 comments · Fixed by #985
Closed

Add a lint for dangerous parent selector use in mixins #892

nex3 opened this issue Dec 6, 2023 · 2 comments · Fixed by #985
Labels
Help wanted 🙋 Help is needed New rule 👌 Ready to be created as a new rule

Comments

@nex3
Copy link
Contributor

nex3 commented Dec 6, 2023

It's relatively common for authors to write selectors like .context & as a way of logically scoping the current style rule to a given context. However, this isn't very reliable in mixins, because the mixin may be included within another nested style rule, at which point the .context may be misplaced.

It would be useful to have a lint for this case to help authors ensure they're not accidentally making assumptions in their mixins. It should specifically warn for & in style rules when:

  • They're within a @mixin.
  • They're nested within another style rule.
  • They aren't at the beginning of a given complex selector. (That is, & .foo is fine, as is .foo, & .bar.)
  • They aren't within @at-root, since that can't be affected by parent style rules anyway. (This isn't accurate, & is still affected by outer style rules.)

It would even be possible to suggest a fix for this by pulling the parent selector into the child and making the child style rule a sibling. For example:

@mixin foo {
  .parent {
    color: blue;

    .context & {
      color: red;
    }
  }
}

could be adjusted to:

@mixin foo {
  .parent {
    color: blue;
  }

  .context .parent {
    color: red;
  }
}
@kristerkari kristerkari added Help wanted 🙋 Help is needed New rule 👌 Ready to be created as a new rule labels Dec 8, 2023
@kristerkari
Copy link
Collaborator

Why not, I guess.

How common is this? Sounds like a quite specific case.

@nex3
Copy link
Contributor Author

nex3 commented Dec 13, 2023

It happens often enough in Google code (and causes enough problems) that we actively want a check for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Help wanted 🙋 Help is needed New rule 👌 Ready to be created as a new rule
Development

Successfully merging a pull request may close this issue.

2 participants