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!
@drewwells This looks pretty neat. I’d definitely be interested in exploring integration here.
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:
paths:
public: 'static'
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!
I tried this (Windows 7 x64) but could not get gulp to complete the build script.
It fails when the hugo command is run.
What makes it super confusing (I’m also new to gulp) is that the hugo project is called hugo (so it’s hard to know what refers to hugo and what to the project).
Also I don’t know if this is a gulp thing, but there are layers of dependency which make modifying it hard. If this is how gulp works, its not for me. Example:
reference:all links to hugo:all and build:all looks for reference:all. I tried to remove the hugo part of the gulp process but it got messy.
Happy to look more into this to get it working and with feedback for others.
Hi @mikeaja, what error message are you getting ?
Could you open an issue on github, with some more details to try and figure it out ?
Error is ‘Command failed’
It doesn’t seem to matter what thhe hugo command is, the error is the same.
I also tried running gulp both in the main hugo folder (where all hugo sites are and where gulp is installed) and also with the project itself. The result is the same.
Could it be that the gulp command is trying to run hugo in the parent (main hugo folder) rather than the project folder?
Still, I’d be happier anyway jjust using the gulp side to do the pre–hugo processing, and running hugo afterwards.
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.
Shameless pluggage:
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.
That’s an awesome idea. Thank you.
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).
If someone is interested, I have published the template I use to work with Hugo projects: https://github.com/csuarez/hugo-gulp-template
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.
The wellington (https://github.com/wellington/wellington) Go wrapper for libsass looked promising - did anything come of that? Might it be integrated into Hugo?
Doesn’t Gitlab build from a gulp script? It also has a runner, which I presumed was something similar to a gulp pipeline
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.
My ideas:
JS/CSS
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…
Images:
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.
I would check if there are Go-native processors available for these tasks (LESS, SASS etc.) before spending too much time on it.
Oh, I thought that was implicit 
Good. But since, to my knowledge, there are no (mature) Go native SASS nor LESS libs, I thought I should give you a heads up.
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.
Edit:
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.
Edit 2:
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.
The only Go SASS compiler I know of is https://github.com/wellington/sass, but it’s very pre-alpha.
5 years from now, Hugo may be able to do many of these things, but it’s going to take people like Drew doing a ton of hard work to get native Go libs.