Hash-ification of filenames of some static resources

Feature requests
1

I’d like to build my SCSS files in such way that the resulting CSS file would have a hash of it’s contents in its filename. This would me allow to set long cache values for the CSS files, which would prevent the need for HTTP roundtrips for those; if the file has changed, the the hash will be different so it isn’t in the cache. The same goes for Web Fonts.

This is something I’m already able to do with processed images, as their filename includes the hash value. Now let’s make it happen for the rest of the static resources too!

2 Likes
2

Again, I’m willing to discuss the feature and contribute a PR if this seems something the maintainers would be interested to have.

3

I would actually find this feature useful. :slight_smile:

4

We already have https://www.getzola.org/documentation/templates/overview/#get-file-hash

I think it makes sense adding it at least for the sass files, less sure about the others. Should it be an opt-in parameter in config.toml?

5

Why would anyone want to turn it off? I would suggest that it is the default behavior.

6

They could be using webpack or other tools instead and already have hashes in their filenames.

1 Like
7

Here’s some more thoughts:

I suspect that if the resource file names get hashed, it would be hard/almost impossible for Zola to automatically find and rewrite all links to those files (because some URLs might be “composed” runtime in JavaScript, etc.), so there ought to be a function that takes in the “input path” and outputs the “hashed path”, that users would use when they refer those resources. That would make the system opt-in, which, to me, sounds also reasonable, as the current system works fine enough.

So, there could be a function that takes a filename as input, reads the contents and hashes it, and outputs a filename that contains the hash as output. Calling that function would also “mark” that file as a file that is copied to public using that hashed name.

What I’d also want to see is being able to customize the pattern of the output file path (this could be a config.toml setting?), as it would make easier in some servers and services (such as Netlify) to mark the hashed files as “cacheable” using glob patterns.

8

Oops, I just realized that even the image filenames that I thought would be okay, don’t work this way, because the hashes are calculated only from the arguments, where the path of the original file is one, but the contents of the file isn’t. I noticed as I retouched a file a bit, and was puzzled why wouldn’t the name change.