If you could have a magic #CSS linter/preprocessor that could flag *any* problems (selector conflicts, bad practices, etc), what would you like it to catch?
I have some fledgling ideas for a new type of #CSS tool. Kind of an opinionated, best-practices-enforcing linter/preprocessor. Trying to determine if the utility it can offer is worth the development effort it would take
@keithjgrant What benefits would it have over using stylelint and sass?

@paulshryock I'm still collecting my thoughts, but the general idea is adding syntax to the language that can clue the linter into more info than raw CSS might do.

For example, enforcing specific cascade layers (ITCSS style) and ensuring the code in each layer "stays in its lane" doing only work it is supposed to do; or wrapping each module/component with an @module rule, so it can know those styles belong together and verify they don't conflict with other modules

@paulshryock I would certainly weave in a lot of existing eslint rules, too, but I'm mostly trying to see if there's enough "extra" it could do to really tackle pain points that eslint alone can't

@keithjgrant I wonder if this stuff could be achieved through a custom stylelint plugin.

https://stylelint.io/developer-guide/plugins/

Not to discourage you from writing a new tool, just throwing it out there in case it would save time and effort and achieve the same thing.

Writing plugins | Stylelint

Plugins are custom rules and sets of custom rules. They might support a particular methodology or toolset, apply to non-standard constructs and features, or be for specific use cases.

@paulshryock I was thinking of using postcss directly, but this would probably be another viable path. good to know, thanks! 👍🏻