I’m not sure if this is out of scope for Hugo, but I thought I’d mention it here to get some input.
As a way to being able to use far future expire headers on CSS and JS files, I’ve been using a method of adding a date to the filename, like: style.20141003.csswhich has served me well. It’s easy to set up a rewrite on the server to just route it to style.css.
Since a rewrite like that isn’t possible on a static server such as S3 (as far as I know at least), I was thinking of a way to solve it on Hugo generation instead, but haven’t been able to figure out a way. It would basically need to rename the file on copy.
The most straight forward solution would be to use the query string way of style.css?v123, but the last time I checked it wasn’t recommended due to issues with some proxies. That way should be possible to do quite easily right now with Hugo though.
Probably related to this topic - but in the current situation it’s not uncommon to combine Hugo with build tools like Grunt or Gulp, which have plenty of tools for this (I use a plugin that put a content MD5 hash into the filenames).
I do eventually want to add some of these features into Hugo, but only when it makes sense. These other tools do a great job already. I think it’s only good to add to hugo when no configuration is needed. As soon as we add a feature that requires a bunch of extra configuration then I feel they are better served in a separate program.
I agree that caching should be configured on the server, but cache busting is useful when we site updates available quickly. Also cache busting allows for longer TTLs on content, which helps
@bep is there a way for me to “inject” data into a hugo build session? I have looked, and did not find anything. I am thinking my build tool (make) could generate a build number, which it would use to name css/js resources. I just don’t see a way to get the build number into the hugo templates. If it could be injected into hugo as a key-value pair, and be available in .Site or a new sub variable in .Site.
cd $(dirname $0)
timestamp=$(timestamp -base 36 -precision min -zero 2015-07-01)
echo "timestamp=$timestamp" | tee timestamp.cfg
mkdir -p $(dirname $OUT)
echo "timestamp: $timestamp" > $OUT
Then I use .Site.Data.build.timestamp in my template partials, e.g.
This presumes there is a directory with name starting with a and containing the timestamp. This is achieved by putting the static files that are ‘far-future’ into static/a and making a symlink like this: