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.
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.
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.
SuitCSS setting for postcssbemlinter is very good for vue/react components, less subjective imho than "block element", its "component root, descendant" instead.
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.
Is anyone aware of a tool that would allow me to manually walk my entire app and any css that doesn't get used can be flagged for deletion?
I find that even with well behaved libraries and tree shaking, my output css still includes a lot of stuff I don't need. (Eg. Yes I use Foo.Button but I don't need all the css for the styles of Foo.Button I never use like circular or large or withIcon)
Chrome has a css coverage tool built in[1]. I suppose it's tricky though, since some html is only visible if there an error (error boxes, etc), or only visible in some rare state (logged in as admin, etc).
I think Svelte does something like that by default. I would love to see more frameworks pick this up. I think it wouldn’t bee hard for e.g. Vue or Stencil to do something similar since they have their own compilers.
I've struggled with this as well. As far as I can tell there isn't a good solution, but I'd love to be proven wrong.
You can run PurgeCSS in a dry mode to find any unused selectors, but it can't handle any classes that are dynamically generated. If your codebase has used anything like `buttonClass = 'button-' + color`, you may get false positives.
The Chrome Dev Tools coverage can show you how much of a stylesheet is used at runtime, but if you concat everything into a single css file that's used for every page, a single page's usage doesn't help.
[+] [-] h3mb3|5 years ago|reply
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/
[+] [-] bryanrasmussen|5 years ago|reply
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.
[+] [-] AltruisticGapHN|5 years ago|reply
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-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-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.
[+] [-] system2|5 years ago|reply
[+] [-] Waterluvian|5 years ago|reply
I find that even with well behaved libraries and tree shaking, my output css still includes a lot of stuff I don't need. (Eg. Yes I use Foo.Button but I don't need all the css for the styles of Foo.Button I never use like circular or large or withIcon)
[+] [-] tyingq|5 years ago|reply
Screenshot of it looking at unused CSS on HN: https://imgur.com/a/TLywsv5
[1] https://developer.chrome.com/docs/devtools/coverage/
[+] [-] fbelzile|5 years ago|reply
[+] [-] mblode|5 years ago|reply
[+] [-] runarberg|5 years ago|reply
[+] [-] cjpearson|5 years ago|reply
You can run PurgeCSS in a dry mode to find any unused selectors, but it can't handle any classes that are dynamically generated. If your codebase has used anything like `buttonClass = 'button-' + color`, you may get false positives.
The Chrome Dev Tools coverage can show you how much of a stylesheet is used at runtime, but if you concat everything into a single css file that's used for every page, a single page's usage doesn't help.
[+] [-] kingkool68|5 years ago|reply
https://developer.chrome.com/docs/devtools/coverage/
[+] [-] genericstorage3|5 years ago|reply