Support for preprocessors

[redalastor]

There should be some support for HTML/CSS/JS preprocessors even if it's just adding shell commands to run in the config.

[redalastor]

Thinking about the issue a bit, I found the following things that would be a must to be able to specify in the config:

• pattern of the preprocessed files
• command to preprocess everything
• command to preprocess a single file
• command to start a watch

Not all of those would be required. If there is no command to preprocess everything then every file is converted individually. If there's a watch mechanism, then hugo doesn't have watch for changes in those files by itself.

[curiouslychase]

This seems like it's asking a lot of Hugo, as Hugo's responsibility is static site generation, not asset processing. You can easily use a build tool such as Make, gulp, grunt, golang's train and watch these files to the /static directory, (from a /src directory), where those files are already being copied to /public.

Hugo, as far as I know, is unaware of the actual assets in the /static directory, just that the files are in the directory to copy to the /public directory, so configuration for a non-standard format seems like a lot of extra cruft built into a tool that's not meant for that.

[adrinux]

That seems an odd distinction @realchaseadams – is Hugo not, essentially, an HTML preprocessor? Can you seriously argue that CSS isn't a part of a static web site?

I was pondering SASS preprocessing since I'm using that to build a site, currently my scss files are in amongst the other files making the site which results in Hugo watch rebuilding once when I save the .scss files and once when compass watch has processed them into .css files in themes/mytheme/static/css – no big deal because it's so fast, but still – so what would best practice be? Keep scss/js etc entirely outside of the site folder? Does Hugo ignore /src?

There's some attraction to letting 3rd party tools do the work they've been designed for, but I'm still having difficulty figuring out the best workflow, filesystem layout etc.

So incorporating a wrapper for something like libsass is out of the question for Hugo?

[curiouslychase]

I wouldn't do anything seriously (sorry if I came across as suggesting there was any real gravity), but I would genuinely argue that a pre-processed asset doesn't belong in the /static directory (because it's not static, it's dynamic), nor should it be processed by, a static website generator.

Hugo won't watch a directory it's not told to watch, and in the case of any pre-processed asset, I'd argue that it deserves to be in a directory outside of the /static directory.

Architecturally, I personally have a /src directory with sass & js files, because I'm ultimately going to want to process and mutate them in a production build, minified, with asset references revved, and not "put" the original SASS or CoffeeScript or LESS files into the public directory, since they don't have a purpose there.

I will run hugo server --watch and my default gulp task, which watched the /src directory for changes, processes assets and writes the new files into the /static directory, which hugo copies into the /public directory. This process works really well for me, and I find that my workflow is better off for it, as well as keeping your statically built assets out of version control if you add /static/css and /static/js to your .gitignore (which I do because I believe built/compiled files don't belong in version control).

When you consider trying to ask hugo to do something like this, there are a lot of architectural decisions you'd have to make:

• Is sass going to be a flag?
• If you incorporate it, is there a schema for where the sass files should live, or should you let the user define it in the config?
• If you're going to have sass as an option, why not offer less, compass, coffeescript, all the other pre-processors that are involved in a workflow?

You made a great point about Hugo being an HTML pre-processor, but I think it speaks more to the fact that Hugo should just be that, an HTML preprocessor that copies static assets into an output directory. The advantage of Hugo is that it's really fast at compiling html assets and copying. Aside from the ease of not having to run sass in a separate shell, what advantage would one gain from having Hugo run a shell command?

I just contribute to the conversation and the cod sometimes, so ultimately the decision isn't up to me, and this is my two cents, which in any economy is pretty worthless, so the decision to incorporate a wrapper for something to compile your sass for you isn't up to me. :)

[igregson]

Interestingly, turns out there a css pre-processor written in Go called GCSS: https://github.com/yosssi/gcss

If some type of css pre-processor support was to be incorporated into Hugo but without support for all of them, perhaps this would be a good one to go with (for no other reason than it being written in Go, for whatever that might be worth). It could be approached in a "zero config" spirit similar to the idea of Harp.

Just a thought related to the topic of Hugo and css preprocessors.

[natefinch]

Hey guys, this is an awesome topic of conversation. I hope you don't mind, but I copied it over to Hugo's official discussion forums, which is a little more appropriate place for this to take place: http://discuss.gohugo.io/t/support-for-html-css-js-preprocessors/127

[dmix]

+1 I'd need a way to add sass support in order for me to migrate away from node.js/ruby static site generators to Hugo.

[alistaircom]

Just discovering Hugo now and I like what I see so far.

Lacking a pre-processor for Sass, or JS or compressing images isn't a big deal, although for Hugo to be successful in the long term, there needs to be an easy way to plug it into an end-to-end workflow.

[dmix]

alistaircom: Indeed, preprocessors are a core feature of almost all of the most popular static site generators. An essential component of front-end dev these days.

[truongsinh]

+1

[sandcastle]

+1 - Pre-processor support is a must for me.

[fgimian]

+1 please 😄

[csuarez]

Until this is supported, I have published the template that I use built with Gulp: https://github.com/csuarez/hugo-gulp-template

I hope that someone find it useful.

[nathany]

I currently use https://github.com/rjeczalik/cmd to watch my sass/** folder and run sassc. My script to do this is here:
https://github.com/nathany/hugo-deploy/blob/master/watch.sh
(it was quite a pain to write that)

It would be nice if Hugo's watcher ran sassc if available: exec.LookPath("sassc"). But it would probably be better if it was configurable.

@omeid Have you used either of Slurp's successors? I'm curious.

@igregson I wonder how compatible GCSS is with Sass. For that approach, I think I'd be more interested in Sassc bindings for Go, so long as it was all statically linked into the Hugo download.

[moorereason]

I use Wellington as my sass processor cmd. Run it in watch mode alongside Hugo.

If Wellington matures to the point where it's 100% Go, we could potentially use it as part of the Hugo site build.

[nathany]

@moorereason I'm not sure if that makes sense in the long term. Much like asset concatenation, spriting becomes an anti-pattern when served with HTTP/2, for the same reasons. See #432 (comment).

[moorereason]

@nathany, agreed. I don't use sprites and don't care for them. That wasn't my point. Wellington uses libsass for many operations, so it's not a great solution for Hugo right now. But he's building out a pure Go sass parser to eventually have a pure Go solution. I think that's very relevant to Hugo and the Go ecosystem.

[nathany]

@moorereason Sorry, I misunderstood. A pure Go sass parser would be awesome, esp. for embedding in tools like Hugo. Achieving and maintaining feature parity is certainly a challenge.

[adrinux]

Integrated Sass parser...except all the buzz is around PostCSS now ;)
I think the approach of having a build tool run Hugo works pretty well.

[ghost]

It would be great if hugo has sass integrated somehow.

[bep]

Note/Update: This issue is marked as stale, and I may have said something earlier about "opening a thread on the discussion forum". Please don't.

If this is a bug and you can still reproduce this error on the latest release or the master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.