Coming Soon: SASS support and more

Announcements
41

Designers in the browser will love this!

3 Likes
42

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?

1 Like
43

Oh, stop! Youā€™re spoiling us :smile:

1 Like
44

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

6 Likes
45

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?

46

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.

For

{{ $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.

47

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.

48

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 forestry.io 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!

2 Likes
49

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.

1 Like
50

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:

3 Likes
51

Yeah, thatā€™s great news. Gorgeous pubs like this one: https://www.getty.edu/publications/intrometadata/

1 Like
52

Quick naming poll:

2 Likes
53

Question,
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)

54

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:

55
56

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 ā€¦

5 Likes
57

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.

58

@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 Resin.io multi-containers and really, really want to maintain my upgrade path.

1 Like
59

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ā€.
1 Like
60

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

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

While a real minification would return:

ol,ul{list-style:none}