PS. This is fantastic. Thanks again @bep
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
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
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
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.
Yes you are right, I noticed that myself, and have it in my very long “TODO list”.
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.
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.
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.
If you start out a sentence with “not to too cynical …” … then you probably are.
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.
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.
scss as well as
sass and this is about more than just one preprocessor, methinks, so
assets makes much more sense…
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.
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.
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.
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.