Coming Soon: SASS support and more


Designers in the browser will love this!


Do we have an ETA on this? I know it’s a brazen thing to ask, but I’m pretty stoked for this feature. Admittedly, I originally thought this wasn’t worth the effort considering the NPM world alternatives, but after seeing how @bep is going to implement this, I can’t wait to give it a spin! Can I help with testing?


Oh, stop! You’re spoiling us :smile:


Plan is to get it merged some time this week. The plan.


Bep, Thank you for all your work on Hugo.

I really want this too. I already use SCSS/SASS for my hugo webstie

Besides cache busting, what is fingerprinting about?

How are you doing the fingerprinting? When I was working on my own solution I used date-time-stamps, but decided it was better to include the git commit hash into the file name. The filename, and thus cache update, only change if the file changes. It’s efficient.

Would it be possible for the finger printing to use the git hash of the commit for the file?


This is the last part of a processing chain, so there is no commit ref until you … commit that file, and that does not sound practical.


{{ $css := resources.Get "styles.scss" | toCSS | minify | fingerprint }}

I currently calculate a MD5 sum of the content output of the minify step (I plan to add options for SHA256 etc., but I think MD5 is common for this).

The fingerprint part is mostly a hash-busting thing. But if we add a Digest method:

So, a person longer up in the thread said something about this being the responsibility of the CDN. But if you care about security, you really want this to happen where you have the most control.


Using MD5 for the hash, and having it do double duty for a Digest sounds reasonable. It also covers my usecase, where the hash will only change if the content changes and thus result in longer lived content and longer valid cache periods.

And I agree, I see no reason not to use Digest at the source; especially if we can make it part of an automated step like you have it.


Just chiming in to say I’m really hyped about this feature. I’ve spent a lot of time racking my brain trying to figure out the easiest way to allow customization of theme styles, and this is the solution I’ve been waiting for!

I’d also like to give a +1 to being able to access config.toml variables in scss files. The content editor can edit params in config.toml, so being able to pass those through to a _variables.scss file would mean I can create themes that are customizable by a user without having to dive into the code. I know that won’t be ready out of the gate, but that would be a killer option for me!


Yea, that will be cool. A little note to the people who have not read all of this carefully:

  • In a project/theme(s) relationship you will be able to put “_variables.scss” (or whatever) in the project and override theme settings. This was what baffled me a little when I tested this out with Chrome Workspaces above. Having these SCSS files spread out on potentially many themes could have made debugging hard (where do I have to change that variable? Theme? Project?). But source maps (and edit and save directly from Chrome) solves that part kind of magically.

The SCSS variables from config.toml will be solved by adding a resources.ExecuteAsTemplate func, which have a ton of other cool use cases. It should not be hard to implement, but will have to wait for the “follow up” release to the thing we have now.

But note that you would only be able to construct the entry SCSS file (e.g. main.scss) this way, but that should give you plenty of power, the way SASS resolves variables.


On an added note, I just got notified that GettyPubs updated their Quire tool from Hugo 0.31 to the latest Hugo release version. There were some concerns that my “bundle release” could potentially mess stuff up, so they have waited … but it went smoothly. Looking at their source, they use SCSS for styling, I guess they can use this as well. The publications they build with Hugo (and some other tools) look beautiful:


Yeah, that’s great news. Gorgeous pubs like this one:


Quick naming poll:


I already have Bootstrap 4 and Prepros setup and running (for SaSS support, I make a change, everything gets updated). What will change for me with this new sass support? (noob question, love me)


Jumping in @Javier_Cabrera, you’ll be able to use your preprocessing setup as you like, or, use the hugo way when it is released. I see the benefit as, you’ll be able to process from within your template.

You can read more here about the concept:



Which is kind of cool. Because this was my biggest concern about all of this, getting this too complicated and shaky build process, when we need the C tool chains for “every” platform … But Docker really shines in this area. And that fits right into the CircleCI release process.

The most irritating part of the work I did tonight was all the updates Windows forced on me. Which is what happens when you boot that Windows 10 image once every 6 months …


Haha, yes that is true. But let’s not be down on Windows here. I have the same problem with various Linux servers. Thankfully, most of them auto-update now but only because I have Webmin configured on them. If you left Windows online with auto-update settings, it would do it all itself. The issue is the size and complexity of the software we use daily, not the OS.

Take Hugo itself - you are releasing updates - what, about every month at the moment? And generally, we are not exposing Hugo itself to the Internet so security risks are pretty low. That isn’t a criticism of course, I love that Hugo is continuing to develop and enhance. But it does highlight the issues we all have with software.

By wrapping the Hugo build process in an npm run script, I can make sure I always have the latest version when I build. This is well worth the occasional hiccup when I have to change something to meet the requirements of a new version.

Anyway, back on topic - as long as I don’t have to mess with Docker simply to get Hugo to compile my site, I will continue to be very happy indeed. If I had to ever deal with Docker and, heaven forbid - Go, to use Hugo, I’d be off finding another tool I’m afraid.


@bep Please take care to ensure this continues to work on ARM. I’m building a new Hugo toy with Balena on the RPi using multi-containers and really, really want to maintain my upgrade path.


Two things:

  • I have hidden the SCSS feature behind a build flag and will relase two binary version.
  • All the resource transformations (SCSS, PostCSS, Minify) will work without these tools if you build from a “prepared repository”. The workflow would be to design, design, design. Then commit the result of that. Then build from Netlify or whatevern – and then you don’t need SCSS, PostCSS installed.
  • The above also applies to theme authors, but I imagine we will have to improve on the workflow here after testing this.
  • The first release will only contain SCSS enabled versions for the platforms I can test myself: OSX, Linux and Windows. We will improve in this department.
  • I would guess that Brew will have no troubles building with the “extended build flag”.


I’m very looking forward to this release, and it even happens to be scheduled on my birthday. :cake: :slight_smile:

Out of curiosity, how is minify implemented?

I ask because Sass (Dart implementation, v.1.7.3.) also offers a ‘compression’ feature, but that feature ‘only’ strips whitespace and unneeded characters – but doesn’t do ‘real’ minification.

For instance,

ol {
	list-style: none;
ul {
	list-style: none;

becomes compressed


While a real minification would return: