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.
The wellington (https://github.com/wellington/wellington) Go wrapper for libsass looked promising - did anything come of that? Might it be integrated into Hugo?
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…
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.
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.
