+1 from me on assets. Just the same arguments as @kaushalmodi (and @FelicianoTech too 
).
PS. This is fantastic. Thanks again @bep 
1 Like
This will be awesome. It seems the only bit missing would be something like PurgeCSS to remove all the unused stuff from the final css file. https://www.purgecss.com
1 Like
Yes, you are right. And I really appreciate thefeed back on names – that is really easy to get wrong. I will bring up a better discussion about these next week.
Agreed. I think of typical JS build tools (that is, tools thag spit out JS) when I think of src and dist and this isn’t doing anything with my script files. assets makes more sense as a default, and in the end if it’s configurable in config.*, you can change it to whatever you want anyways…
Wondering if this would instead be able to point to css/main... rather than scss/main... just as a means of convention (and since themes are scaffolded with a css dir) @bep, but this is a pretty small detail regardless. Very excited to see this feature and all the cool bells and whistles you’ve mentioned above 
Out of curiosity, is there plans to include Param keys in the Sass (or maybe it’s not even possible)? Something like $primary: .Site.Params.primary_color would be really cool
3 Likes
I agree. But not in the first round. (at least I think not – I have a resource.Template func (or something) in the plans that would enable this, but my plate is full as it is).
But you will still have lots of powers with the first release.
If you look at
And also think about the powerful theme components composition and inheritance support added recently, doing these overrides in the project with a “_variables.scss” overrides etc. is getting stuff done. Having that same colour as a variable in config.toml isn’t adding much.
3 Likes
Yes you are right, I noticed that myself, and have it in my very long “TODO list”.
3 Likes
Can’t wait tho 
as always - awesome
thx for the hard work
Just dropping in a few thoughts… Trying not to be too cynical here but whatever.
-
Use of
assetsdirectory as a default will match Jekyll and make porting conceptually easier. -
Where there is Sass there should also be Source Maps. IMO these should be delivered together.
-
Intuition tells me as soon as this feature is released no fewer than 52 sniveling JavaScript developers are going to bang on the door asking “when postcss” and “when typescript” so just be ready for the potential to lose market share to Next, Nuxt and Gatsby if promises aren’t readily available.
-
Here are two useful Sass libraries I’ve used in the past: Susy, Breakpoint. I learned about both of them by studying Michael Rose’s code and I recommend anyone getting into Sass do the same as there’re heaps of old, unsupported Sass libs out there sure to cause some approaching Hugo grow some chest hair investigating.
Looking forward to getting my hands on this though I plan to keep cache busting at the server or CDN level (and out of the webapp) where it belongs.
2 Likes
If you start out a sentence with “not to too cynical …” … then you probably are.
6 Likes
This thread is going off topic fast, but I will just comment this: Fingerprinting and resource digesting is only partially about cache busting – and I’m not letting some random server in the cloud to do that job for me.
3 Likes
Back to the topic at hand, please use the sass directory for sass files. You know what they say about assets. Just kidding. Seriously though please use sass k tks bye. 
Could be scss as well as sass and this is about more than just one preprocessor, methinks, so assets makes much more sense…
1 Like
I like to see that Hugo evolves and grows that quickly. Also SASS/SCSS is probably something which will be used by many people, but honestly I’m hesitating a bit if I like it or not.
There are many great asset pipelines out there, which can compile SASS/SCSS and many other things along with it. Why make Hugo more complex with integrating SASS/SCSS instead of integrating existing solutions?
It’s not like I’m writing a SASS compiler here. This is a libsass integration. It is a very opniated choice, but I really want this, and judging by the response I have gotten after the announcement, I’m not alone.
And “integrating existing solutions” completely isn’t really possible. You will end up with with a half-baked solution:
- Only Hugo knows about the layered filesystem that is the project and the themes, so you would not get any SASS support in themes (think "_variables.scss overrides etc.)
- It would proably be much slower. Doing SCSS edits on a themed Bootstrap 4 and get reloads < 200 ms is something you have to experience.
- Installation.
Also, the SASS support is the “sales pitch” in all of this – but the main part here is a streaming chain of resources processors. I have deliberately named the SCSS step ToCSS; we will eventually get some other – possibly a plugin format.
I have worked with setting up these asset pipelines in Gulp and similar. The clarity and simplicity of declaring this in one place, where it is used, is a clarity I’m willing to give up lots of flexibility to get. And then there are the obvious other benefits from having an integrated solution, like speed and inheritance from the virtual filesystems in Hugo.
4 Likes
That said, from the next version of Hugo we will provide a double set of binaries: One with and one without SASS. This is just because there may be OSes where we may not be able to support SASS from day one (there is work involved building this). But you can do the “prepare step”, so to speak, on a SASS-enabled Hugo, and then later use that source to build from a “leaner variant” on Netlify etc.
3 Likes
OK, so after some head scratching today, I got SASS source maps up and running and working in combo with Chrome Workspaces, and this is powerful combo. I say again: Hugo + SCSS + Chrome Workspaces makes a very powerful combo. Right click, inspect element, click on the relevant SCSS file, edit, cmd+save … rebuild/reload … Magic. All from inside Chrome. And with when you override SCSS files in project from the theme(s) it takes you to the correct file inside Chrome Very, very nice.
11 Likes