Works like a charm now, thanks a lot @bep
$ brew upgrade hugo
Brew log
Updating Homebrew…
==> Auto-updated Homebrew!
Updated 2 taps (homebrew/core, homebrew/cask).
==> Updated Formulae
hugo 
dovecot go-statik hadolint math-comp odpi sshguard u-boot-tools
coq fn goreleaser libuv mvtools shairport-sync tox yaz
==> Upgrading 1 outdated package, with result:
hugo 0.39 -> 0.43_1
==> Upgrading hugo
==> Downloading https://homebrew.bintray.com/bottles/hugo-0.43_1.high_sierra.bottle.tar.gz
==> Downloading from https://akamai.bintray.com/73/7328049dec0c12bece16306258592277ab8b908c4e0dd797aa1a97a268d5468f?gda=exp=1531218806~hmac=6b7c303dd3c6ea3292b3f98ca280
######################################################################## 100.0%
==> Pouring hugo-0.43_1.high_sierra.bottle.tar.gz
==> Caveats
Bash completion has been installed to:
/usr/local/etc/bash_completion.d
==> Summary
/usr/local/Cellar/hugo/0.43_1: 32 files, 54.6MB
$ hugo version
Hugo Static Site Generator v0.43/extended darwin/amd64 BuildDate: unknown
Great, but looking at that file size, they (we) should add the “-ldflags=”-s -w"" to shrink it … But that can wait …
What do the -s and -w switches do? I built Hugo locally with and without those, but couldn’t see any difference. Also, I don’t know where to look for the documentation of those switches… do they have long-form versions?
That is how we build it for the release binaries, and the effect is dramatic.
Thanks! I’ll notice the binary size next time… found the doc for those switches from your link: https://golang.org/cmd/link/.
Hi folks, sorry if this is a stupid question, but is there any downside to running the extended version if I’m not currently using SCSS? I don’t fully understand why there are two different binaries. I see in the release notes you say “if you don’t use SCSS, you will most likely want the non-extended version”, but why? Is the extended version slower or something?
It is:
- Bigger (binary size)
- On Linux and OSX it is not fully static. You will have to have a compatible version of Libc++ installed, which you most likely will have on your personal PC, but maybe not if running in a minimal CI setup in a Docker container.
Other than that, it should be the same.
Did anyone manage to run extended Hugo build on Netlify?
I tried downloading and adding the extended Linux 64 binary in my repo and I got:
4:31:49 PM: Executing user command: bin/hugo -b $DEPLOY_PRIME_URL
4:31:49 PM: bin/hugo: line 1: version: command not found
4:31:49 PM: bin/hugo: line 2: oid: command not found
4:31:49 PM: size: '20991192': No such file
Why do you need that? I had a workflow in mind where Netlify would run with “prepared assets”; i.e. you commit the files below “resources/_gen/assets” and let Netlify use that.
With Hugo 0.43 I could remove 5 Gulp plugins (gulp-uglifyes, gulp-cssnano, gulp-concat, gulp-rev, and gulp-rev-replace) from my Gulp file. Pretty cool! 
(The gain is little bit bigger, because now I can also use SCSS, for which I didn’t have plugins.)
This makes my workflow a little bit easier. And I don’t have to work with a Gulp file anymore that was already 300 lines. Plus that Hugo is a lot quicker too, of course!
The only things left on my wishlist are minification of the rendered HTML (to drop my last Gulp plugin) and much better JavaScript minification (which requires changes upstream). My JavaScript files are around 15-20% bigger than they were with gulp-uglifyes, but that hopefully gets better in the future.
This is the “Hugo 0.43” announcement thread, and not a place for lengthy trouble shooting.
Sorry, I’m being a bit thick here. Previously, I’ve committed my site source folder which includes a static folder containing css/js/etc.
So now, if I want to use the Hugo pipeline to merge and minify my css and js - does that mean that I would need to build the site locally, commit that?
I feel that I’m missing something. Or should I wait for a Netlify blog post on the matter?
Apologies if I’ve missed something as I’ve been away from everything in Iceland for a while, just getting back into things.
You don’t have to do that.
But in my mind, here is what I want to do:
- I want to design and develop my site (SCSS etc.)
- When that is done, I want to spend the next 6 months writing content for my now beautiful site.
- I see no point doing a full assets pipeline every CI build for every typo in a Markdown file. There will also be CI servers where the SCSS enhanced binary and PostCSS installation isn’t practical/possible.
- And I care about security, so I add sha256 integrity hashes. I would not trust a CI server in the cloud to do this for me. Having those commited to GitHub makes a difference: The code that I built is also the code that is running.
The above is the reason why I carefully crafted this workflow where you can commit your generated assets output below /resources and (hopefully) forget about until you need to adjust some colors.
You don’t have to work this way. It’s just my recommendation.
But note that Hugo will only fall back to the generated assets if a tool that is in a given pipe isn’t available, i.e. PostCSS not installed, running from a non-extended Hugo version.
Also, the above is gold if you want to build themes for the crowd …
And a fine suggestion it is! I’m not questioning this, I want to make use of it, I’m just trying to understand how to actually do it.
I’m in no hurry, I’ve already had a massive increase in performance just from moving from Wordpress on a VPS to Hugo on Netlify. 
I’m sure the documentation will catch up as people have time to work on it, I’m happy to wait. I’m sure it will click into place at some point.
If I understood well, I can build my theme with the extended version and the theme users can remain using the normal version. If I saving the generated files in the theme repository, will everything work in the unextended version of Hugo?
The short answer is yes. There is probably missing some “tools” to make this simpler, but Hugo reads both /assets (where it looks for assets to process) and /resources (file cache) in both project and theme(s), so if a theme generates everything into /resources – and the project does not need to do any styles changes or whatever, it just works.
And this of course gets even more useful in the future if the build setup gets even more complicated with plugins etc.
Oh! So if the asset has already been generated, you don’t need to worry about doing it on the CI side. That’s really wonderful that you built it to fall back like that. Your point about generating the sha256 hashes locally is a good one.
A note re. the SHA256 hashes – if the CI server has all the tools needed to “build the pipeline” (SCSS, PostCSS, whatever), it will build it (even the hashes). We may find that we need a way to “lock this” or whatever, but there are simple ways to control this (by not installing PostCSS on CI), or checking the hash against your GitHub version etc. Plenty more secure than letting the Cloud do it.
Thanks so much for this. One question, and I’ll admit I haven’t looked into how PostCSS is integrated, is whether you would be able/willing to offer a libsass alternative? PostCSS is great, but I recently switched my site to sassc because it was exceptionally faster, and had a lot less dependencies. My experience with PostCSS wasn’t bad, but there was a lot more work involved, which was very easy with sassc—and did I mention much much faster.