I’m just getting started with Hugo, but I’ve been using it long enough to see the breakneck pace at which Hugo is developing. I spent some time trying to get a promising theme working, where it said on the tin “Requires Hugo 0.15 or later”. Fine, I’ve got 0.17. One minor detail: the home page rendered nearly blank, the partial bracketed with “with .Site.Params.Header” was not rendered. To make a long story short: the theme referred to variables in config.toml using CamelCase, and somewhere between 0.15 and 0.17 it became mandatory to refer to them in lowercase. The theme author obviously hadn’t upgraded yet and was surprised that his theme had broken. As a theme user, it was not obvious that the Hugo upgrade had caused this.
Once I figured it out, it was an easy fix, but it triggered me to think: if I start depending on Hugo for my web site, I’d like to be able to upgrade with confidence, and not have rendering issues go undetected.
I started looking if I could find a way to have Hugo warn about undefined references. Obviously, just adding a flag to Hugo to warn about undefined references won’t fly, because the “with” clause specifically tests for whether or not the object is defined and thus should suppress the warning.
So, what can one do to prevent this? Any best practices for testing themes? I come from a world where rspec rules suppreme (and I’m new to the Go ecosystem, but I’m willing to learn anything that is likely to be accepted by the theme author). Just a simple smoketest like “The home page should include a div#banner”, “div#banner should include an img href=/img/banner.jpg” would have prevented this, and (when done in a way that exercises all the moving parts of a theme) would give me the confidence to go ahead with Hugo. I’m not afraid of fixing stuff after an upgrade, I’m afraid of not knowing it broke in the first place!
Apologies if I’m asking the obvious, but my limited GoogleFu didn’t turn up much!
