New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for preprocessors #16

Closed
redalastor opened this Issue Aug 6, 2013 · 21 comments

Comments

Projects
None yet
@redalastor

redalastor commented Aug 6, 2013

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

@redalastor

This comment has been minimized.

redalastor commented Aug 7, 2013

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.

@chaseadamsio

This comment has been minimized.

Contributor

chaseadamsio commented Sep 14, 2014

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

This comment has been minimized.

adrinux commented Sep 16, 2014

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?

@chaseadamsio

This comment has been minimized.

Contributor

chaseadamsio commented Sep 16, 2014

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

This comment has been minimized.

Contributor

igregson commented Sep 26, 2014

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

This comment has been minimized.

Contributor

natefinch commented Sep 26, 2014

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

This comment has been minimized.

dmix commented Oct 14, 2014

+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

This comment has been minimized.

alistaircom commented Nov 25, 2014

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

This comment has been minimized.

dmix commented Dec 7, 2014

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

This comment has been minimized.

truongsinh commented Feb 7, 2015

+1

@spf13 spf13 modified the milestones: v0.13, v0.14 Feb 22, 2015

@sandcastle

This comment has been minimized.

sandcastle commented Jul 17, 2015

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

@anthonyfok anthonyfok modified the milestones: v0.15, v0.14 Sep 16, 2015

@anthonyfok anthonyfok modified the milestones: v0.16, v0.15 Nov 30, 2015

@fgimian

This comment has been minimized.

fgimian commented Apr 1, 2016

+1 please 😄

@csuarez

This comment has been minimized.

csuarez commented Apr 15, 2016

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

This comment has been minimized.

Contributor

nathany commented Apr 19, 2016

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

This comment has been minimized.

Contributor

moorereason commented Apr 19, 2016

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

This comment has been minimized.

Contributor

nathany commented Apr 19, 2016

@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

This comment has been minimized.

Contributor

moorereason commented Apr 19, 2016

@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

This comment has been minimized.

Contributor

nathany commented Apr 19, 2016

@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

This comment has been minimized.

adrinux commented Apr 19, 2016

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.

@moorereason moorereason modified the milestones: future, v0.16 May 7, 2016

andrewhowdencom added a commit to andrewhowdencom/www.andrewhowden.com that referenced this issue May 26, 2016

Move the scss out of the static directory
This seems like a good idea. "static" is kind of like "staging", and
you stick files in there just prior to generation.

See gohugoio/hugo#16 (comment)
@declanqian

This comment has been minimized.

declanqian commented Jun 2, 2016

It would be great if hugo has sass integrated somehow.

@bep

This comment has been minimized.

Member

bep commented Mar 1, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment