What causes me to constantly shudder is when I have to use project wide search to find the class name on an element so I can see what was caused the computed styles in the browser to occur.

  1. Find source file with class name. See the scss extension, dread rises a bit.
  2. See scss file has multiple @import directives and uses multiple custom functions.
  3. Open up 4 more scss files to see what those imports and functions do. See that those files also use @import directives. Find some Malort, take a shot.
  4. Repeat step 3 until arriving at root of style hierarchy or pass out.

That's why Tailwind works. It may result in a very long line of small classnames to represent all the styles across many breakpoints, but at least you don't have to deal with somebody else's own little hellish adventure into perfectly reusable scss.

But these are self-inflicted wounds. Having standards and validation for CSS is easy. No need for all of this. No need for SASS either. Install Stylelint and there you are.

I've encountered this situation in multiple projects where style lint was enabled, with only the defaults, and passed the linter without issue.

Tailwind is seeing steadily increasingly popularity (and the accompanying backlash) because it is straight forward and does not require something like stylelint to keep you from hurting yourself.

Well, that is not using Stylelint I'd say. Within half a day of configuring, you can prevent almost all of the problems denounced in this thread.

Ultimately, it really is "a couple hours of thinking/configuring a linter vs. multiple layers of abstraction, complexity and dependencies added to the codebase."

Maybe I'm missing something (and be my guest if I do!) but there is an objectively better choice here.

Well, that means stylelint has a problem. They should be talking about how to solve it, because nobody wants to not enable debuging information on a develoepr build. If the devs do not acknowledge this as a problem, this means stylelint is a bad piece of software.

I really dislike sass the way it's normally used. It was once a necessary hack, but it's mostly not useful anymore. Something that just concatenates your CSS @include on deployment would bring more value nowadays.

I'm not sure what you mean about "Stylelint having a problem".

There's a default config, with only base rules, without the more opinionated ones. Then you configure/extend it as you would with almost any other tool. Isn't it the way most tools of this kind work?

Or am I missing something?

Linters default rules define almost completely how they will be used. It doesn't matter if you think this is reasonable or not.

IMO, missing some rules is better than what most tools of this kind do, but something as plain and obvious as "did you enable debugging symbols on the development build?" should be there. And most people will blame the tool if it's missing.

Sorry if I'm being obtuse but I still don't understand.

As I see it, the problem was one of SASS code architecture. What do you mean then by "enable debugging symbols"? How does that solve the "chaotic file architecture" problem?

I don't know what magic stylelint does that I'm not aware of that helps with this. We used stylelint with a massive project and everything was nice and "clean" yet CSS debugging was a nightmare. At least with Tailwind I can look at the classes and tweak exactly what I want

If you give me a couple of examples, I can give you Stylelint rules to prevent them. At least I think so... eheh.

And now that I think about it, that would be a great exercise in fact! Yes, I'd really appreciate it if you have some in mind and would post them here.

I'm all ears (eyes)!