DartSass: An installer for sass

If you would like to migrate away from node/npm/webpack while still using sass, the dart_sass package provides a installer and runner for Dart Sass via Mix.

This package follows the same structure esbuild– you add your configuration to config.exs:

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

and then you can run it from your command line:

$ mix sass default --version

For any Phoenix projects currently using Sass via webpack, you can use dart_sass to model your asset pipeline in the upcoming style of the Phoenix v1.6 installer.

First, add DartSass as a watcher in config/dev.exs:

sass: {
    [:default, ~w(--embed-source-map --source-map-urls=absolute --watch)]

Note: this requires Phoenix > v1.5.9.

…and then create or add sass to your "assets.deploy" alias in mix.exs:

"assets.deploy": ["sass default --no-source-map --style=compressed", "phx.digest"]

You may refer to the README for more details, and if you are using dart_sass in a project, please let us know!


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


Maybe Elixir installation could include Wasm runtime in the future so these tools wouldn’t need its own. Then you could run these tools as wasm binaries in any OS. Dart for example is looking into Wasm compilation Experimenting with compiling Dart to Wasm, and calling Wasm from Dart | by the Dart team | Dart

1 Like

While it seems awesome I would really like to see something like PostCSS with postcss-preset-env, so I would be able to use CSS-proposed nesting and other features from CSS proposals instead of SCSS “custom” solutions.

1 Like

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 know. My question was more “maybe someone know something like PostCSS that is built into native executable”.

1 Like

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.


You might want to check out GitHub - mnussbaumer/cssex: An Elixir based and opinionated way to write CSS . It supports nesting, etc. Still haven’t gotten around to really testing it, but the option is there. Not sure how it compares to postcss.

1 Like

I love the idea. I’d suggest to build something that is source compatible to a curated subset of tailwind/postcss, usable without any Elixir specific syntax. This way it can have a much larger audience.

I wonder if one could build a standalone PostCSS binary with something like vercel/pkg :thinking:

Hypothetically speaking, if one were to port PostCSS to Deno, would that fulfill your goal of sidestepping Node? Or would the same issues regarding reproducible builds persist?

EDIT: Deno support · Issue #1430 · postcss/postcss · GitHub

@amnu3387 would be the expert in that. That would be quite incredible if that could work. I know he was looking at quite a few specs.

Super-interesting idea. I suppose the stability would depend on how many dependencies are pulled in to create it, but at least the end-user would be guaranteed a working tool.

There are Tailwind-like CSS frameworks written in SASS, https://uniformcss.com/ for example. However, I don’t know how CSS purging is done in sass. I guess you have to use PurgeCSS and with that you have dependency on node. This is a tough nut to crack :slightly_smiling_face:

1 Like

Deno is much less compelling for me, but admittedly it’s because I expect churn there as well given the proximity to the js ecosystem and early lifecycle, which may be an unfair bias. I would love something that allowed me to achieve the tailwind css design language/feature-set with either an elixir port or failing that, single binary executable, which is what deno could offer. That said, it would need to be a complete solution – not only the postcss bits. I imagine for most folks, the tailwind cli is hard to beat for up and running and simple builds, but long term I don’t trust node packages to continue to work from where I left off, and it is unnacceptable to me that to change a css rule somewhere five years from now, I may be left with days of work when revisiting a perfectly happy app. These requirements are not everyone’s requirements so to be clear, as implemented, tailwind and tailwind cli are great choices for many folks :slight_smile:

1 Like

neat! I had not been aware of this previously. Looks like really interesting work!

Wow, this opens a new gate for me! On the front-end, it’s a bit hard to do CSS tree-shaking if the HTML comes dynamically from the backend. But if the CSS is generated on the back-end, we can predict which CSS rules will never be used!

1 Like

And the heex html engine could easily lift out class information so this kind of thing could work really nicely together.

1 Like



Thank you. I have successfully purged node from my laptop.


Thank you very much, exactly what I was looking for!

1 Like