Whoops. Thanks for the catch. I was trying to trim down some of my CSS the other day, but inadvertently forgot to leave my `--cyan-700` variable. The yellow you saw was supposed to warn me, "Hey, you missed one!" but I apparently missed that one. :-/ Fixed.
Don't use Hugo. The maintainers are so detached from reality it's not even funny. The project is about 12 years old, has +80k stars on github and used in production by many. Despite that still no 1.0 version and they introduce breaking changes for no good reason. You website will break all the time. I made a mistake of creating few websites with it and now I have to rewrite them all in other SSG because I refuse to participate in this circus.
Can't agree, even though I was also hit by breaking changes from time to time with my own templates. Because this has a BIG upside: I am very happy with Hugo and how they love to solve problems in detail and think through features to the end. Because of these frequent re-factorings and sometimes (!) breaking changes, it gets more elegant every year.
And this is really not a production problem. As stated in the comments before, just don't upgrade if you don't want to / have no time yet. It is a self-contained static site generator without external dependencies. It won't break. And the security of an old Hugo binary is mostly a non-issue if you do not load remote content.
And, if you have some time: Their changes are really well documented. The changelogs are really good.
The main problem is sticking with an unmaintained template of a third party which breaks when you finally want to upgrade and don't want to fork / don't know when a an template update comes along. But that's the reason I write my own. It was worth the effort.
Eh. It’s written in go. I just built the binary, stuffed it in my repo and continued to use the same version for years. Then when I wanted to update I rewrote my whole theme from scratch, recompiled and now I’m set for years again.
and a convenience symlink ~/.local/bin/hugo, pointing to my "production" version. I can easliy call whichever version I like with hugo<tab><tab>. What am I missing?
It depends on your workflow I guess, but the advantages of having a Hugo version tagged in an image:
- sharing it easily between computers/users (docker pull registry/image:tag)
- having the appropriate binary version embedded in your code through a docker-compose in your repo
- having custom aliases dedicated to hugo included (build/serve/run...)
- using the exact same image in your CI/CD
- not "polluting" your local computer with some more stuff
Author here. This post arose out of a recent thread on the Hugo Discourse:
https://discourse.gohugo.io/t/hugo-v0-158-0-released/56868
Good call out from that thread is he's trying to get a small change in esbuild added to help with this as well.
https://github.com/evanw/esbuild/issues/4419
Yes; hope that gets blessed. We shall see.
BTW, there's a glitch in your code snippet syntax highlighting; in Light mode, the 'p' selector is remaining an unreadable yellow.
Whoops. Thanks for the catch. I was trying to trim down some of my CSS the other day, but inadvertently forgot to leave my `--cyan-700` variable. The yellow you saw was supposed to warn me, "Hey, you missed one!" but I apparently missed that one. :-/ Fixed.
Don't use Hugo. The maintainers are so detached from reality it's not even funny. The project is about 12 years old, has +80k stars on github and used in production by many. Despite that still no 1.0 version and they introduce breaking changes for no good reason. You website will break all the time. I made a mistake of creating few websites with it and now I have to rewrite them all in other SSG because I refuse to participate in this circus.
Can't agree, even though I was also hit by breaking changes from time to time with my own templates. Because this has a BIG upside: I am very happy with Hugo and how they love to solve problems in detail and think through features to the end. Because of these frequent re-factorings and sometimes (!) breaking changes, it gets more elegant every year.
And this is really not a production problem. As stated in the comments before, just don't upgrade if you don't want to / have no time yet. It is a self-contained static site generator without external dependencies. It won't break. And the security of an old Hugo binary is mostly a non-issue if you do not load remote content.
And, if you have some time: Their changes are really well documented. The changelogs are really good.
The main problem is sticking with an unmaintained template of a third party which breaks when you finally want to upgrade and don't want to fork / don't know when a an template update comes along. But that's the reason I write my own. It was worth the effort.
Eh. It’s written in go. I just built the binary, stuffed it in my repo and continued to use the same version for years. Then when I wanted to update I rewrote my whole theme from scratch, recompiled and now I’m set for years again.
Yes that's exactly what I did.
I have a docker image with a given version of Hugo and I've been using it for years now.
That's the beauty of building HTML: you don't HAVE to stay up to date to get security fixes.
Is there a reason for OCI images? It is just a binary? I have all used versions in ~/.local/bin/
and a convenience symlink ~/.local/bin/hugo, pointing to my "production" version. I can easliy call whichever version I like with hugo<tab><tab>. What am I missing?It depends on your workflow I guess, but the advantages of having a Hugo version tagged in an image:
> Then when I wanted to update I rewrote my whole theme from scratch
I think that's what OP complains about here
Good idea, sounds like the only sane way to use it.
Yeah Bryce!
[dead]
Nice! (But I must say that Zola has this built-in since forever.)
For Sass, yes[0] --- as has Hugo[1]. Hugo's recently added `css.Build` function, based on esbuild, is for post-processing vanilla CSS.
[0]: https://www.getzola.org/documentation/content/sass/
[1]: https://github.com/gohugoio/hugo/releases/tag/v0.43 (July, 2018)