Gotcha. Agree this would be amazing since I really love tailwind (which heavily builds on postcss), but the long term repeatability of my css builds years down the road is a concern without such a thing.

This looks awesome. I can’t wait to not have to install node or npm ever again.

The goal is to sidestep the node ecosystem and related baggage/reproducible builds by installing the precompiled binaries for DartSass in this case. If postcss could provide something similar that would be amazing, but afaik this is not something easily done given postcss’s node implementation.

I just published v0.2.0:

• No longer load config/runtime.exs by default, instead support --runtime-config flag
• Update initial sass version to 1.39.0
• mix sass.install --if-missing also checks version

First, this DartSass installer is awesome. Thank you, @mcrumm!

In terms of using standalone Tailwind and DartSass together, here’s something I’ve been experimenting with that might help…

In educational apps specifically, I often want to avoid using a lot of Tailwind utility classes in templates. To do that, I rely on Tailwind’s @apply directive. And when it’s a fairly significant amount of CSS, it’s often handy to use CSS nesting which is where DartSass comes in.

Here’s an example css/app.scss file that demonstrates the problem in an abbreviated form:

@tailwind base;
@tailwind components;
@tailwind utilities;

.card {
  @apply p-4 bg-blue-300 text-blue-800 rounded-lg;

  & .title {
    @apply text-2xl tracking-tight font-bold;
  }

  & .details {
    @apply pt-4 text-lg font-medium;

    & a {
      @apply underline;
    }
  }
}

Now if you run that file through the Tailwind CLI alone, it won’t flatten out the nesting. (The @tailwind/nesting package isn’t baked into the Tailwind CLI as far as I can tell).

However, you can first run that file through DartSass and then run the result through the Tailwind CLI. In other words, pipe the output of one into the other.

Here’s how I’ve been doing it:

First, setup the watchers in the right order:

  watchers: [
    dartsass: {DartSass, :install_and_run, [:default, ~w(--watch)]},
    tailwind: {Tailwind, :install_and_run, [:default, ~w(--watch)]}
  ]

Then configure dart_sass to process app.scss and drop the result in an intermediate file named app.tailwind.css for example:

config :dart_sass,
  version: "1.49.0",
  default: [
    args: ~w(css/app.scss ../priv/static/assets/app.tailwind.css),
    cd: Path.expand("../assets", __DIR__)
  ]

Finally, configure tailwind to use the DartSass output file as its input and spit out the final output in app.css:

config :tailwind,
  version: "3.0.18",
  default: [
    args: ~w(
      --config=tailwind.config.js
      --input=../priv/static/assets/app.tailwind.css
      --output=../priv/static/assets/app.css
    ),
    cd: Path.expand("../assets", __DIR__)
  ]

I’ve only been experimenting with this for a couple days, so there are likely limitations I haven’t bumped into yet.

Is that the sort of thing you’re trying to do, @hxgdzyuyi?

I look forward to hearing of better ways to do this.