Any interest in improved sass integration?

[jasonhulbert]

I created a proof of concept at work for a utility-first library that can be used as either/both a postcss plugin or as a sass plugin.

Basically, the core library is responsible for processing a set of plugins and configs - similar to what Tailwind is doing. The difference however is that the project contains implementations specific to both postcss and sass.

In the case of Postcss, the implementation is a plugin and is used the same as Tailwind.

In the case of Sass however, the implementation is a custom sass importer provided via the importer sass option. Sass Plugins

Using It looks like this:

Either as a sass module:

@use '[library-name]:utilities' as utils;

.example {
  @include utils.apply('w-8', 'bg-gray-400');
}

Or as a sass import:

@import '[library-name]:utilities';

.example {
  @include apply('w-8', 'bg-gray-400');
}

The syntax is of course different between the 2 implementations. Beyond the obvious reasons, it's like this so that the usage feels "more at home" within the respective language. For example, broken syntax highlighting in sass for unquoted strings that contain a hyphen).

After having gone through the process of creating the POC, I felt like it was worth seeing if there was any interest here. I personally feel like this would be a very welcomed addition to Tailwind. Or maybe it's better suited as a companion tool that is distributed as a separate package but uses tailwind behind the scenes to process plugins/configs (so as not to reinvent the wheel in a separate project).

[alinnert]

I was about to ask a similar question. Mainly for two reasons:

1. Performance: At work I'm maintaining a project that contains multiple websites that inherit and overwrite a "master theme" based on postcss + cssnext. Back then I was still figuring things out so maybe I did something very wrong. But building just the css takes about one minute! On the other hand Sass now provides a binary version written in Dart that - according to benchmarks - runs almost as fast as the C++ implementation. In every project I use Sass building css basically takes no time at all.

2. IDE integration: I like the idea of @apply. That's why I chose PostCSS over Sass in the project mentioned above. But then the @apply CSS proposal was withdrawn which basically makes it a proprietary solution. Also, PostCSS IDE plugins basically just highlight every unknown @ rule without knowing what it actually does. That means that IDEs cannot provide auto completion for @apply (and also @tailwind). If Tailwind was based on a more widespread and more supported technology stack it could leverage the already existing IDE plugins or language features.

IMHO: Because of this I not only think that supporting Sass is a good idea, I'd rather move Tailwind entirely over to Sass. Especially because Sass recently introduced modules (@use, @forward etc.) which allows for dependency resolution similar to JS/TS.

When it comes to syntax:

The easiest solution (that could be done right now) would be to translate all Tailwind classes to Sass placeholder selectors. Instead of: .mx-1 { ... } it would be %mx-1 { ... }. They behave like classes but Sass won't output them in the final css file unless they're being used at least once.

You can use them like this, which is very similar to the currently existing @apply:

.btn {
  @extend %mx-2, %my-1;
}

The only question is how this can be customized.

When it comes to a pure Sass solution I'd go with utility mixins. Something like this:

@use "tailwind" as *;

.btn {
  // Just some syntax ideas:
  @include margin(2); // mx-2 my-2
  @include margin(2, 1); // mx-2 my-1
  // or should the parameters above be swapped to match how "margin: 8px 4px;" works in CSS?
  @include margin($x: 2, $y: 1); // mx-2 my-1

  // Group utilities to reduce the number of @includes needed.
  @include font($family: "sans", $size: "xl", $weight: "medium");
}

Plus: you could actually configure Tailwind from within Sass like this:

@use "tailwind" with (
  $border-radius-4xl: 2rem
);

This could even be centralized by using @forward:

@forward "tailwind" with (
  $border-radius-4xl: 2rem
)

Then you could use your customized version like this:

@use "./my-custom-tailwind" as *;

This would be a dream...

[jasonhulbert]

@alinnert Thanks for keeping the conversation going and I tend to agree with a good portion of what you've said.

However, there's a few things here I'd like to clarify/correct.

Use of sass placeholders

The biggest shortcoming / pain-point with Sass placeholders is that they cannot cross media query boundaries. So, in the example you've provided, if the placeholder %mx-2 is declared at the "root", it cannot be used within a media query. You could potentially work around this by implementing a nightmarish amount of breakpoint-specific placeholders but that would result in duplicate styles across media queries and would force you to only use the pre-configured media queries. There's been quite a bit of discussion/explanation regarding this limitation over the years.

The original purpose of this suggestion

Instead of choosing one or the other (Sass or PostCSS), I have a POC that proves out my original suggestion. That is, a single set of configs that are adopted by both a Sass plugin and a PostCSS plugin. The Sass plugin is a set of importers and functions. This, to me, is the ideal state. A common tool that can be used with either CSS pre/post-processor. This would give our dev teams the ability to pick which one best suits their project while subscribing to the patterns and conventions that we have agreed upon across the org.

Because the config is a javascript file, it's relatively easy to accomplish this. The challenges would be maintaining feature parody between the two and also ensuring that the potential of one is not limited by the other.

My team's solution

We've created a Sass library that we are quite happy with. Instead of taking a completely different direction, we've adopted the use of the apply term and since it is no longer part of the spec it's all the more reason to use it (in our opinion). It's now just a term that aptly describes the functionality of our library's mixin.

Creating/Modifying plugins is trivial and can be done at any point before the apply mixin is used. The short explanation is plugin/utility rules are managed in a global sass map.

The below example creates a utility/plugin named align-items. You can add rules ad-hoc using this mixin so it's easy for users to modify/add. For the time being, we have created plugins that maintain feature parody with Tailwind but we plan on separating entirely in the near future in order to accomplish some specific goals that would benefit our devs internally.

@use '@org/lib/plugins' as pl;

@include pl.add-plugin-rules(
    'align-items',
    (
        'items-stretch': (
            align-items: stretch,
        ),
        'items-start': (
            align-items: flex-start,
        ),
        'items-center': (
            align-items: center,
        ),
        'items-end': (
            align-items: flex-end,
        ),
        'items-baseline': (
            align-items: baseline,
        ),
    )
);

We also created functions that make repetitive / generated rules easier to create. This is similar to how the Tailwind source is written (in js).

The below example adds w- (width) sizing scale rules using the pre-configured sizing scale (which matches that of Tailwind). The last argument of the create-sizing-scale-rules function is a list of properties to which the size value should be applied.

@use '@org/lib/plugins' as pl;

@include pl.add-plugin-rules(
    'width',      
    pl.create-sizing-scale-rules('w-', (width))
);

Using the plugins is straight-forward and would feel very familiar to Tailwind users.

@use '@org/lib/plugins' as pl;

.ex {
  @include pl.apply(
    'flex',
    'items-center',
    'bg-gray-100'
  );
}

We have come to prefer this line-break syntax as it is easier to read and results in smaller code diffs. The quotes are optional but we prefer them for syntax highlighting reasons.

Lastly, we've include a convenient breakpoint mixin for concise and easy-to-use media queries based on the pre-configured screen sizes (which also match that of Tailwind).

@use '@org/lib/plugins' as pl;

@include pl.breakpoint('lg') {
  .ex {
    @include pl.apply(...);
  }
}

A really cool aspect of this is that we can greatly optimize the compile-time by off-loading the work related to generating our giant map of style rules to a Sass function written in javascript that augments a global variable containing all rules. In doing so, even with thousands of utilities, the compile time should be fast.

[alinnert]

Oh, thanks, I didn't know about that problem with placeholder selectors. I haven't used them so far but they seemed to perfectly fit this use-case.

Yes, I agree, opening up to multiple technologies is a better idea than limiting to just one. I just didn't expect this to be possible.

Your approach is pretty interesting. The only thing I don't like about it is that it uses strings. That way editors cannot warn you about typos or provide auto completion. But I also think that it would help if Sass was more type-safe and provided something similar to TypeScript's union types (type size = 'sm' | 'md' | 'lg').

[jasonhulbert]

Yep, agreed - I think many of us wish there were better control/safety checks in CSS in general but since that's just a dream at this point you should check out this VS Code extension which provides Tailwind intellisense. https://marketplace.visualstudio.com/items?itemName=bradlc.vscode-tailwindcss

It's in our backlog to create the same thing for our sass library in vs code and webstorm.