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.
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.
[1] https://stylelint.io/user-guide/rules/no-descending-specific...
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.
This requires in my experience using a consistent bem syntax otherwise specificity snowballs pretty fast.
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.
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.
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.