# Coming Soon: SASS support and more

**URL:** <https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429>\
**Category:** Announcements\
**Created:** [June 14, 2018, 9:19pm UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429 "2018-06-14T21:19:33Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![bep](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/bep/32/3332_2.png) [@bep](https://discourse.gohugo.io/u/bep)\
**Post date:** [June 14, 2018, 9:19pm UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/1 "2018-06-14T21:19:33Z")

</div>

![hugo-sass3](https://canada1.discourse-cdn.com/flex036/uploads/gohugo/original/2X/4/41433d8e71faa30a0b04f34948368d3179d22272.gif)

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:

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

```

Which produces this:

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

```

---

<div class="post-metadata">

**Author:** ![szac](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/szac/32/5358_2.png) [@szac](https://discourse.gohugo.io/u/szac)\
**Post date:** [June 14, 2018, 9:36pm UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/2 "2018-06-14T21:36:30Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Leo\_Merkel](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/leo_merkel/32/3321_2.png) [@Leo\_Merkel](https://discourse.gohugo.io/u/Leo_Merkel)\
**Post date:** [June 14, 2018, 9:57pm UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/3 "2018-06-14T21:57:17Z")

</div>

Can‘t wait. What a great evolution! 👏

---

<div class="post-metadata">

**Author:** ![lucperkins](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/lucperkins/32/1280_2.png) [@lucperkins](https://discourse.gohugo.io/u/lucperkins)\
**Post date:** [June 15, 2018, 5:58am UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/4 "2018-06-15T05:58:07Z")

</div>

@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?

---

<div class="post-metadata">

**Author:** ![bep](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/bep/32/3332_2.png) [@bep](https://discourse.gohugo.io/u/bep)\
**Post date:** [June 15, 2018, 6:50am UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/5 "2018-06-15T06:50:22Z")

</div>

> [@lucperkins](#):
>
> @bep Will Hugo watch other files beyond the main Sass file for changes?

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:

```bash
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 …

---

<div class="post-metadata">

**Author:** ![dmgawel](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/dmgawel/32/5933_2.png) [@dmgawel](https://discourse.gohugo.io/u/dmgawel)\
**Post date:** [June 15, 2018, 8:37am UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/6 "2018-06-15T08:37:18Z")

</div>

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

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?

---

<div class="post-metadata">

**Author:** ![bep](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/bep/32/3332_2.png) [@bep](https://discourse.gohugo.io/u/bep)\
**Post date:** [June 15, 2018, 8:43am UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/7 "2018-06-15T08:43:38Z")

</div>

1. [https://github.com/wellington/go-libsass](https://github.com/wellington/go-libsass) – 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.

---

<div class="post-metadata">

**Author:** ![bep](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/bep/32/3332_2.png) [@bep](https://discourse.gohugo.io/u/bep)\
**Post date:** [June 15, 2018, 8:51am UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/8 "2018-06-15T08:51:36Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Mooash](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/mooash/32/11724_2.png) [@Mooash](https://discourse.gohugo.io/u/Mooash)\
**Post date:** [June 15, 2018, 9:11am UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/9 "2018-06-15T09:11:10Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![bep](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/bep/32/3332_2.png) [@bep](https://discourse.gohugo.io/u/bep)\
**Post date:** [June 15, 2018, 9:14am UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/10 "2018-06-15T09:14:45Z")

</div>

> [@Mooash](#):
>
> 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.

---

<div class="post-metadata">

**Author:** ![alexandros](https://avatars.discourse-cdn.com/v4/letter/a/ecc23a/32.png) [@alexandros](https://discourse.gohugo.io/u/alexandros)\
**Post date:** [June 15, 2018, 9:16am UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/11 "2018-06-15T09:16:57Z")

</div>

How about `dep` from dependencies? Or something similar.

But I also like `assets`

---

<div class="post-metadata">

**Author:** ![Mooash](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/mooash/32/11724_2.png) [@Mooash](https://discourse.gohugo.io/u/Mooash)\
**Post date:** [June 15, 2018, 9:21am UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/12 "2018-06-15T09:21:45Z")

</div>

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

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

---

<div class="post-metadata">

**Author:** ![FelicianoTech](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/felicianotech/32/22886_2.png) [@FelicianoTech](https://discourse.gohugo.io/u/FelicianoTech)\
**Post date:** [June 15, 2018, 1:44pm UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/13 "2018-06-15T13:44:04Z")

</div>

`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.

---

<div class="post-metadata">

**Author:** ![kaushalmodi](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/kaushalmodi/32/2567_2.png) [@kaushalmodi](https://discourse.gohugo.io/u/kaushalmodi)\
**Post date:** [June 15, 2018, 1:46pm UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/14 "2018-06-15T13:46:10Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![kaushalmodi](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/kaushalmodi/32/2567_2.png) [@kaushalmodi](https://discourse.gohugo.io/u/kaushalmodi)\
**Post date:** [June 15, 2018, 1:49pm UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/15 "2018-06-15T13:49:10Z")

</div>

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](https://www.thefreedictionary.com/words-that-end-in-ify).

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

---

<div class="post-metadata">

**Author:** ![bep](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/bep/32/3332_2.png) [@bep](https://discourse.gohugo.io/u/bep)\
**Post date:** [June 15, 2018, 3:26pm UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/16 "2018-06-15T15:26:18Z")

</div>

> [@kaushalmodi](#):
>
> Also, how about `toSass` instead of `Sassify` ?

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.

---

<div class="post-metadata">

**Author:** ![kaushalmodi](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/kaushalmodi/32/2567_2.png) [@kaushalmodi](https://discourse.gohugo.io/u/kaushalmodi)\
**Post date:** [June 15, 2018, 3:31pm UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/17 "2018-06-15T15:31:42Z")

</div>

> [@bep](#):
>
> We’re not converting anything to `SASS`

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 🙂

---

<div class="post-metadata">

**Author:** ![kaushalmodi](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/kaushalmodi/32/2567_2.png) [@kaushalmodi](https://discourse.gohugo.io/u/kaushalmodi)\
**Post date:** [June 15, 2018, 3:33pm UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/18 "2018-06-15T15:33:26Z")

</div>

> [@bep](#):
>
> `sass.ToCSS` which reads better.

+1. That’s even better, yes.

---

<div class="post-metadata">

**Author:** ![lucperkins](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/lucperkins/32/1280_2.png) [@lucperkins](https://discourse.gohugo.io/u/lucperkins)\
**Post date:** [June 15, 2018, 3:36pm UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/19 "2018-06-15T15:36:21Z")

</div>

@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](https://webpack.js.org/) default to a similar approach.

---

<div class="post-metadata">

**Author:** ![bep](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/bep/32/3332_2.png) [@bep](https://discourse.gohugo.io/u/bep)\
**Post date:** [June 15, 2018, 4:11pm UTC](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429/20 "2018-06-15T16:11:49Z")

</div>

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.

[Next page](https://discourse.gohugo.io/t/coming-soon-sass-support-and-more/12429.md?page=2)