5 ms·

Hmm... I wonder why stylelint wasn't mentioned? [1] I thought it was nowadays kinda the CSS equivalent to ESLint. We added it (in tandem with Prettier) to a co

by h3mb3 6y ago

Hmm... I wonder why stylelint wasn't mentioned? [1] I thought it was nowadays kinda the CSS equivalent to ESLint. We added it (in tandem with Prettier) to a codebase that uses lots of old SCSS. So far it's been a good gatekeeper as the team has been growing, blocking the most questionable .scss edits in PRs. We had to disable and ignore many of the rules to fit it together with our legacy files though. [1] https://stylelint.io/ https://stylelint.io/

bryanrasmussen 6y ago
Linting tools tend to be a combination of rules that make your code nicer to look at by some relatively arbitrary stylistic convention and rules for keeping out code that because of the nature of the language can lead to footguns. Stylelint in my experience is almost all, if not all, about enforcing stylistic convention. I can't stand it because I do not find most of the stylistic conventions enforced to actually improve legibility.
- h3mb3 6y ago
  In my experience there are a fair amount of rules in the second category of yours (anti-footguns). For instance, preventing invalid properties alone is a huge one. There are also rules like [1], a few violations of which popped up in our legacy styles. No dev of ours would've caught those. [1] https://stylelint.io/user-guide/rules/no-descending-specificity https://stylelint.io/user-guide/rules/no-descending-specific...
  - bryanrasmussen 6y ago
    hmm, maybe it's just that I am only being caught out by the styling rules, or maybe it is that I am pretty good at understanding the cascade so the linked example is actually something that - while probably a footgun - for me is likely to be annoying because I actually wanted to do what I did. But I guess deploying a footgun is often a minimum two person job: first person writes code that when used wrong will shoot in foot but they would never use wrong, next person actually pulls the trigger.
- AltruisticGapHN 6y ago
  I agree with the sentiment but as other user pointed out, there are quite a few rules that can enforce very strict limits on css selectors complexity : limiting sibling selectors, descendants, limit combined ( eg. .foo .bar .baz = 3 parts ), low specificity even down to 1, disallow ids, !important, etc. This requires in my experience using a consistent bem syntax otherwise specificity snowballs pretty fast.
  - minusf 6y ago
    why is disallowing id's a feature? it makes headless testing so much more easier, amongst other things.
    - AltruisticGapHN 6y ago
      Ids overpower everything else in the css cascade, in particular any utilities like tailwind’s (unless you activate !important for utils, which also has its cascading effects and heavyhanded fix). Using an id is not inherently wrong, and with stylelint you can always disable a rule for the exceptions, with a comment of the form /* stylelint-disable-next-line <optional specific rule id> */ Nowadays esp. with composition methodology it’s almost always better to just use a unique bem like class, eg. .HomepageHero-carousel , even if the element in question is a "singleton"... because later someone can stick a mb-4 on it, or a text-lg , or even your own custom utility or modifier and it will stick, without snowballing css selector complexity.
    - AltruisticGapHN 6y ago
      I didn’t understand your reply at first. If you use ids for easy targeting parts of html, then it doesn’t matter, stylelint doesn’t check the html. Applying styles can be done via classes so the css selectors in your stylesheets do not need to mention any #ids. Applying styles with #ids however, is an issue.
AltruisticGapHN 6y ago
What’s missing is postcss-bem-linter With it you can actually enforce bem like syntax, low specificity, so your scss plays well with the utility / composition methodology eg. tailwind but also custom utilities. https://github.com/postcss/postcss-bem-linter#preset-patterns https://github.com/postcss/postcss-bem-linter#preset-pattern... SuitCSS setting for postcssbemlinter is very good for vue/react components, less subjective imho than "block element", its "component root, descendant" instead. https://github.com/suitcss/suit/blob/master/doc/naming-conventions.md#suit-css-naming-conventions https://github.com/suitcss/suit/blob/master/doc/naming-conve... You declare the component for which the following css applies, eg /* @define UserAvatar */ , so the linting is far more useful. You’re linting the classnames to enforce consistent naming based on components, not just a stylistic choice. Unfortunately it takes some work to setup a strict stylelint config and properly configure postcssbemlinter, maybe i should post mine as a gist ... there is no premade config afaik, I think very few people used this kind of strict linting... tailwind became succesful and people saw it as the solution, and completely disregarded the middle way in the process as if writing custom css was inherently bad. Tbh many stylelint base rules seem pointless, like complaining about #ffddee should be written #fde..m who cares? Minifiers take care of this. Sadly postcssbemlinter + Suitcss setting is a bit buggy around tailwind directives like @apply, but it’s functional enough used it two years on a nuxt project, with a strict low specificity config it really helped me rethink how to simplify selectors and avoid css spaghetti. TLDR i feel like a thorough bem/bem-like linter is what’s missing from most projects still using scss, because i’ve seen some really awfull bem css, it’s not enough to have a guideline, it needs strict checking to improve css quality.

by h3mb3 6y ago

bryanrasmussen 6y ago

Linting tools tend to be a combination of rules that make your code nicer to look at by some relatively arbitrary stylistic convention and rules for keeping out code that because of the nature of the language can lead to footguns. Stylelint in my experience is almost all, if not all, about enforcing stylistic convention. I can't stand it because I do not find most of the stylistic conventions enforced to actually improve legibility.

h3mb3 6y ago
In my experience there are a fair amount of rules in the second category of yours (anti-footguns). For instance, preventing invalid properties alone is a huge one. There are also rules like [1], a few violations of which popped up in our legacy styles. No dev of ours would've caught those. [1] https://stylelint.io/user-guide/rules/no-descending-specificity https://stylelint.io/user-guide/rules/no-descending-specific...
- bryanrasmussen 6y ago
  hmm, maybe it's just that I am only being caught out by the styling rules, or maybe it is that I am pretty good at understanding the cascade so the linked example is actually something that - while probably a footgun - for me is likely to be annoying because I actually wanted to do what I did. But I guess deploying a footgun is often a minimum two person job: first person writes code that when used wrong will shoot in foot but they would never use wrong, next person actually pulls the trigger.
AltruisticGapHN 6y ago
I agree with the sentiment but as other user pointed out, there are quite a few rules that can enforce very strict limits on css selectors complexity : limiting sibling selectors, descendants, limit combined ( eg. .foo .bar .baz = 3 parts ), low specificity even down to 1, disallow ids, !important, etc. This requires in my experience using a consistent bem syntax otherwise specificity snowballs pretty fast.
- minusf 6y ago
  why is disallowing id's a feature? it makes headless testing so much more easier, amongst other things.
  - AltruisticGapHN 6y ago
    Ids overpower everything else in the css cascade, in particular any utilities like tailwind’s (unless you activate !important for utils, which also has its cascading effects and heavyhanded fix). Using an id is not inherently wrong, and with stylelint you can always disable a rule for the exceptions, with a comment of the form /* stylelint-disable-next-line <optional specific rule id> */ Nowadays esp. with composition methodology it’s almost always better to just use a unique bem like class, eg. .HomepageHero-carousel , even if the element in question is a "singleton"... because later someone can stick a mb-4 on it, or a text-lg , or even your own custom utility or modifier and it will stick, without snowballing css selector complexity.
  - AltruisticGapHN 6y ago
    I didn’t understand your reply at first. If you use ids for easy targeting parts of html, then it doesn’t matter, stylelint doesn’t check the html. Applying styles can be done via classes so the css selectors in your stylesheets do not need to mention any #ids. Applying styles with #ids however, is an issue.

AltruisticGapHN 6y ago

What’s missing is postcss-bem-linter With it you can actually enforce bem like syntax, low specificity, so your scss plays well with the utility / composition methodology eg. tailwind but also custom utilities. https://github.com/postcss/postcss-bem-linter#preset-patterns https://github.com/postcss/postcss-bem-linter#preset-pattern... SuitCSS setting for postcssbemlinter is very good for vue/react components, less subjective imho than "block element", its "component root, descendant" instead. https://github.com/suitcss/suit/blob/master/doc/naming-conventions.md#suit-css-naming-conventions https://github.com/suitcss/suit/blob/master/doc/naming-conve... You declare the component for which the following css applies, eg /* @define UserAvatar */ , so the linting is far more useful. You’re linting the classnames to enforce consistent naming based on components, not just a stylistic choice. Unfortunately it takes some work to setup a strict stylelint config and properly configure postcssbemlinter, maybe i should post mine as a gist ... there is no premade config afaik, I think very few people used this kind of strict linting... tailwind became succesful and people saw it as the solution, and completely disregarded the middle way in the process as if writing custom css was inherently bad. Tbh many stylelint base rules seem pointless, like complaining about #ffddee should be written #fde..m who cares? Minifiers take care of this. Sadly postcssbemlinter + Suitcss setting is a bit buggy around tailwind directives like @apply, but it’s functional enough used it two years on a nuxt project, with a strict low specificity config it really helped me rethink how to simplify selectors and avoid css spaghetti. TLDR i feel like a thorough bem/bem-like linter is what’s missing from most projects still using scss, because i’ve seen some really awfull bem css, it’s not enough to have a guideline, it needs strict checking to improve css quality.