Comments (22)
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.
from hugo.
It would be great if hugo
has sass
integrated somehow.
from hugo.
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. :)
from hugo.
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
from hugo.
+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.
from hugo.
+1 - Pre-processor support is a must for me.
from hugo.
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.
from hugo.
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.
from hugo.
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.
from hugo.
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?
from hugo.
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.
from hugo.
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.
from hugo.
+1
from hugo.
+1 please 😄
from hugo.
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.
from hugo.
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.
from hugo.
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.
from hugo.
@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).
from hugo.
@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.
from hugo.
@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.
from hugo.
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.
from hugo.
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.
from hugo.
Related Issues (20)
- Edit of of functions/_common/* in Hugo Docs not reflected on server rebuilds HOT 1
- livereload.ForceRefresh doesn't (always) work in Chrome HOT 1
- hugo server -N behaves oddly when editing headless content
- Apple MacOS ARM64 broken build for large sites "Error: error building site: TOCSS: failed to transform" HOT 5
- navigation.Page is nil for taxonomy pages (Hugo v0.128.2+) HOT 3
- List page publish date now defaults to that of the latest subpage HOT 5
- Performance Improvements in Template Execution HOT 3
- Deferred template crashes server HOT 5
- Fingerprint appended twice causing file name too long
- Adjust gitmap execution HOT 1
- Ability to customize the fingerprint delimiter that goes in between the filename and extension
- extend version on Mac gives "ld: warning: ignoring duplicate libraries: '-lc++', '-lm'" error massed on go install HOT 3
- Emoji :melting_face: Unable to render HOT 2
- YAML format not set in front matter HOT 2
- Invalid URL for the author page if multiple authors are enabled HOT 2
- exif: Warning when GPS lat/long not set HOT 2
- Unicode Bidirectional Algorithm Support
- The development environment is normal, the production environment is blank. HOT 1
- `--watch` not working with helix-editor HOT 7
- debs for hugo extended should use a different package name and conflict HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hugo.