Coming Soon: SASS support and more

The above screenshot shows a Hugo rebuild on change with full compile of a themed Bootstrap 4 SASS source.

I will bring up a debate on the naming in a little bit once I get this ironed out a little more, but the current syntax looks like this:

 {{ $styles := resources.Resource "scss/main.scss" | resources.Sassify | resources.Minify | resources.Fingerprint }}
<link rel="stylesheet" href="{{ $styles.RelPermalink }}" media="screen"><script>

Which produces this:

<link rel="stylesheet" href="/scss/main.min.eae6b4ebececc2bbd7490966a5e01bcc.css" media="screen">

Fantastic! Looking forward to it. Great work @bep.

1 Like

Can‘t wait. What a great evolution! :clap:

1 Like

@bep Will Hugo watch other files beyond the main Sass file for changes? If my style.sass imports a variables.sass, will that be watched as well?

It will watch everything. In the demo above I’m changing the “_variables.scss” file not the main. Note that this is still a prototype (working one), but what I want to do is possible, just needs some work … But is very, very cool.

  • I’m adding another top-level directory, default /assets. Conceptually it is the same as /static – just that nothing gets copied to /public (only the processed artifacts).
  • You can add anything to this folder (it is being watched for changes), but currently I have:
assets/scss => my main.scss and variables etc.
assets/vendor/bootstrap => the bootstrap source as a submodule
  • You can make changes to any file inside /assets and it wlll trigger a rebuild.
  • You can have /assets folders in themes/theme components.
  • A common use case would be to have the SASS source live in the theme, but add a custom _variables.scss or similar in the project with custom colours etc.

There are potential even cooler stuff to be done with this in the future (templating …), but that will have to wait. I think I have promised too much already …


Hi @bep, thanks for your work and dedication to assets pipeline in Hugo. This looks very promising. I have some questions :slight_smile:

  1. What’s under the hood? Are you using some pure Go SASS compiler or just Go wrapper for libsass?

  2. I already use /assets directory in many of my Hugo projects, and its the source for my webpack pipeline. It would be great to have some config flag to opt-out from Hugo processing of this directory (it’s unnecessary trigger a Hugo rebuild if my /assets are processed by any other tool).

  3. Are resources referenced by CSS files (i.e. images loaded by url()) resolved and copied by any way?

  1. – which is unfortunate in that it complicates the build. I will add a build tag for it, so you can opt out of it if you want, and I have to wait before I can promise a SASS enabled build for all of the exotic platforms we build for (but Linux, Windows and MacOs will be covvered). But we have waited too long for a native Go SASS compiler, not happening in short term. If I’m wrong, please point me to a solid implementation.
  2. Set assetDir = something else in your site config. We need another dir for this, and /assets was the first that popped into my mind, which is usually a good sign. But it isn’t set in stone.
  3. No.
1 Like

If someone have a better and less likely conflicting name for “assets”, please chime in …

I like src since it’s the “source” you’re compiling from. Assets make me think of images and stuff that make up the website.


I can add to this that this folder will also be used as a search path for

  • images for “ad hoc processing”
  • javascript for concatenation/minification/fingerprinting
  • etc.

In all of the above, you may not want to copy the original to public, only the processed version.

1 Like

How about dep from dependencies? Or something similar.

But I also like assets

Hmm yeah fair enough. I think I like src still, plus it’s shorter :grinning:

Assets could make more sense given the rest of the folders Hugo uses (public, static etc) are all full words and not shortened.

1 Like

assets sounds good. I don’t like src because I already have my Hugo files in that directory because they all are the source files for the generated website.


+1 on assets… has very distinct meaning unlike resources and src.

1 Like

Also, how about toSass toCSS instead of Sassify? When I read “something-ify”, it sounds like it’s converting to that “something”.

  • Minify makes sense as that converts to a minified version.

See Words that end in -ify.

(markdownify is a bad precedent as it converts from markdown to HTML)


We’re not converting anything to SASS. But I agree that Sassify is bad. Thinking about adding it to its own template namespace and make it sass.ToCSS which reads better. We will probably also need some type of options “object” for this, and that reads better living in its own namespace.

Sorry… typo/thinko… I meant toCSS. I was thinking that “Sassify doesn’t actually convert ‘to SASS’”, and I ended up typing that by mistake :slight_smile:

1 Like

+1. That’s even better, yes.


@bep I think that the separate assets folder approach is fantastic. In my projects I typically have a source folder with subfolders like sass and js that are fodder for processing (I use Gulp to process and push everything into static). I think that I’m far from alone in this and feel like this should be considered a best practice. Tools like Webpack default to a similar approach.


A note mostly to myself:

  • My biggest concern about adding this to Hugo is that the only viable option is CGO with Libsass, which has its drawbacks. Mostly it complicates the build process, but there will be semi-exotic-OSes we will not provide “SASS-enabled binaries for” – at least from the start.
  • So we can add a build tag etc. to disable it in certain situations.
  • But since you will most likely not fiddle with SASS files all the time, we should be able to load a cached version of the generated assets, even if the version you are currently building with is not “SASS-enabled”.

The above is just notes to self. I’m adding this. The main reason is that I really want this feature for myself, and judging by the reactions to my tweet last night, I’m not alone. I’m happy to take some pain to get this. Watiing for a native Go SASS implementation is going to take forever.