Some feedback / problems with sass in Radicle

In Radicle, I’m trying to remove tailwind and use sass.

  1. Removing the tailwind item from .stylelintrc should be added to docs, will throw errors if you don’t catch that

  2. Documentation doesn’t mention that “'@roots/bud-sass” needs to be added to the bug.config.js file under radicle.extensions.add

  3. postcss breaks on valid sass double slash // comments

  4. There’s hardcoded tailwind in the framework?

app/View/Composers/App.php

public function with()
{
    return [
        'containerClasses' => 'max-w-5xl mx-auto',
        'containerInnerClasses' => 'px-6',
        'siteName' => $this->siteName(),
    ];
}
  1. Related to above, I think this was introduced in Radicle and is deriving the classes from the above. Is it necessary?

             <div class="{{ $containerInnerClasses }}">
    
  2. the stylelint section is titled “Configure Stylelint (optional)” – but because stylelint is already configured, this doesn’t seem optional. It was throwing “customSyntax” errors with the default stylelint content

1 Like

Thanks for the topic! Radicle is more opinionated than Sage is and there aren’t plans to document the use of Sass or removing Tailwind specifically for Radicle, but the Sage guide for it should hopefully cover most of it

#3: This can probably be fixed by modifying the Stylelint config :thinking: Give this a shot? https://roots.io/sage/docs/replacing-tailwind-with-bootstrap/#5-configure-stylelint-optional

#5: Correct, this is not necessary if you don’t want it in your boilerplate

#6: That guide is specific to Sage, and Sage does not come with Stylelint configured out of the box

Oh that’s too bad, I didn’t know that. I think those doc suggestions above apply to Sage too?

Hope you guys’ll consider making Tailwind simple to drop, it’s a polarizing style of development that adds a lot of cognitive overhead if you’re not familiar with it.

Sage’s bud.js config doesn’t add extensions the same way as Radicle & Sage doesn’t ship with a Stylelint config, but if I’m missing something else please let me know

You should only have to remove it once if you’re treating Radicle the way we intend it to be treated (as a boilerplate)

We understand Tailwind isn’t for everyone, but Radicle’s current state and future plans will be tied to Tailwind CSS (some out of the box Alpine.js + Tailwind CSS + Blade based components are on the roadmap)

At the very least it would help if there were semantically significant classes alongside the hardcoded tailwind stuff. We can’t reasonably target this:

<div class="text-red-50 bg-red-400">
  Sorry, no results were found.
</div>

From here:

    public $types = [
        'default' => 'text-indigo-50 bg-indigo-400',
        'success' => 'text-green-50 bg-green-400',
        'caution' => 'text-yellow-50 bg-yellow-400',
        'warning' => 'text-red-50 bg-red-400',
    ];

Is the intention to also have opinionated design? It might not matter once customization is complete, but I was hoping to stay in step with updates without having thorny merges.

Why would you need to target those classes rather than updating the component to return the classes that you want to use?

FWIW, that is from Sage 10 and hasn’t had a change in over 2 years.