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
What’s under the hood? Are you using some pure Go SASS compiler or just Go wrapper for libsass?
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).
Are resources referenced by CSS files (i.e. images loaded by url()) resolved and copied by any way?
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.
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.
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.
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.
@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.
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.
