I maintain a Go wrapper for libsass at: https://github.com/wellington/wellington. Rather than creating a port of Sass to Go, this leverages the work of libsass which will be 100% compatible with the Sass specification. Wellington builds with the standard Go toolchain. If there’s some interest in integrating these, I’ll take a look at the hugo project and see what is needed.
I really like Hugo and it would be awesome to use Sass with it!
I’d highly recommend using Brunch as your build system. It mimics the Rails asset pipeline, supports all the standard preprocessors, and compiles to the public directory by default. Follow the instructions in the guide inside your Hugo site and you’ll be up and running in no time.
Since I just got started with Hugo, I didn’t realize that static is the intended location for static assets. You’ll want to add the following to your brunch-config.coffee:
module.exports = config:
Now, run hugo server --watch in one terminal session, and brunch w in another. Whenever you make a change to your Sass files, for example, they’ll be automatically compiled to static, and Hugo will reload the browser. Nifty!
Bit late to this party but I’ve recently switched from using Textmate to Atom and, one of the packages I’ve installed in Atom is Less-Autocompile, which automatically pre-processes .less files into their corresponding .css file. All you need to do is add a couple of lines of comment at the top of the .less file to tell Less-Autocompile where to output the compiled .css file and it will automatically generate it, every time you hit save.
I’d be a bit wary of over-burdening Hugo itself with too much ‘everything but the kitchen sink’ functionality [Although a plugin system might mitigate this a bit].
Anyway, having previously abandoned attempts at working with CSS pre-processors because of the lack of integration with my [then] workflow, I’m pretty impressed with how seamless my newly discovered Atom + Less-Autocompile makes it.
I’ve written about this and a bunch of other packages I find useful in Atom here:
Given that probably 90%+ of the time I spend in Atom is working on my Hugo sites [whether writing posts, hacking templates or building themes], it may be of interest to others of you looking for a near-as-dammit “one stop shop” for your Hugo tinkering.
I also don’t get on with CSS pre-compiliers in the workflow. I find the ‘static source of Hugo’s static source’ approach, to store the .less, .styl, etc for the conversion to Static folders CSS quite messy.
I like the logic here and it could be a goood fit for me as I see CSS pre-processing as separated anyway to a workflow (it depends only on itself and the CSS output is determined at the point of saving the file, whereas other parts of pre-compiling depend on integrating layouts, partials, etc).
Just to add another voice saying that this is a must for me.
I’m trying to choose which static site generator to use with GitLab Pages, which supports many generators. I was excited by the prospect of a super-quick Go-based generator, and Hugo gets good reviews, but if I can’t build my Sass automatically when I push to my repository, that’s a deal-breaker. So I’m going to have to go with something more full-featured.
If there’s a need for it I’d glady update my Yeoman generator (generator-hugo) for this. I’m currently maintaining a gulp generator for Jekyll (generator-jekyllized) as well but it wouldn’t really be a problem for me at all to maintain the generator for hugo as well since there’s a big overlap between them.
The only thing that I’d miss from Jekyll is being able to have two configurations where one contains the dev environment settings and the other the production settings, so that you could override the dev settings with the ones in production. It’s something I do in Jekyll which is really great.
I’ll look into updating the hugo generator some time either today or later this week.
Hmm. I pretty much hate the idea of letting other tools do the pre- and postprocessing of “static” files. I will look into in how to add pre- and post- processord for js and css, and also for the possibility to template these files. One nice thing would be to auto-version css & js files and to increase them if the file has changed.
I am using hugo to create web pages for non technical people and I really hate every step increasing the difficulty to manage the project or to install it locally. To prevent breakage with backward-compability I have planned to put static content which need to be processed (js, css, images(resizing)) into a new folder called “resources” or “assets”.
I will need a bit of time to get familiar with the sources. If I have sorted everything out and startet working on it I will post here again linking to a merge request (WIP) or an issue on github.
Inline-css is a nightmare but it is the only possibility to work with at the moment to manipulate colours in configruation files and to create colour profiles of matching colours. And I do not like that. Neither will I accept that as a status quo.
In other words: I will work on it and would be happy if there are other interested people to support this idea and process.
parse “assets” for go-templates (configure colour familiy in configtuation, etc…)
run pre-processor over assets (less/scss -> css; iced/coffee ->js)
run post-processor over assets (minify. Can be turned off by a variable called “debug” set to “true”. If active also rename assets in html templates to “*.min.css/js”)
copy the assets into destination directory.
I am also thinking to provide some different colour calculation methods out of the box all with the same API and also configurable in the main config. What need to be implemented, too, is versioning of css/js. I am thinking on using a hash as version. pro: will not change when the file has changed. Contra: Not unique, file could change without a change in the hash…
I would like to have something for image processing (minifying and size adaption). One usage example would be the “favicon” or image galeries (generate a small version of the image for preview). This could be realized with something like “assets/path/image.jpg|300x200” (will later be “/path/image-300x200.png”) or with user defineable size variables.
I would appreciate some thoughts about that before I will start trying to implement this from top to bottom.
For SASS there are libsass wrapper (native implementation of sass in c). My only concern about them is that they need libsass which need gcc to compile (which is no problem if the terminal is git-bash or cygwin)…
A full compile would also need a lot more time because libsass need do be rebuild every time (which is easy to not do by install libsass and link against that library). Why I do not want to use wellington: The documentation stats it is not compileable in windows
LESS has no c-compiler
To compile Iced/CoffeScript I could think of using node if installed and if not give the opputunity to compile the files via a portable node which will be “installed” automatically if needed.
That is not the best solution I can think of but it is pretty good if I do not want to mess with ruby and node myself. Having only one executable and the project directory as a requirement to run the website.
Using a wrapped node would also make the libsass library obsolete which will improve the compile-speed by increasing the build time of the website for the first build only.
Why am I thinking this is still much more useable than using “requrejs”, “bower”, “gulp”, etc…
When showing my clients the website I created for them I give them the project directory and one executeable (hugo.exe in most cases) and it just works. It is as simple as doubleclick on hugo.exe or hugo-server.exe (packed bash-script starting the server) and they can see the results or try modifying the page for themselfs. It is just simple and works without any issue.