-
Notifications
You must be signed in to change notification settings - Fork 31
Optional asset fingerprinting? #20
Comments
I need to look at the code, the cascaded dependencies in gulp tasks may probably make this not exactly trivial. :) |
Correct. None whatsoever. CloudCannon and Siteleaf, Cloud CMS's for static sites, do the same transparent cache busting. Im not sure about Neflify, but I'd wager they're doing the same as a part of the deployment pipeline following builds. If I understand it correctly, adding the cache headers would be as simple as getting MD5 sum of the file contents (or SHA, in case of DCVS), and busting those assets with a new ETAG or Cache-Control headers at the CDN-level. |
Nice! I think I'll have some free time this weekend, so I'll work on hugulp a bit. |
May I ask how this is coming along? I came here wondering the same thing as jhabdas. Thanks. |
Hi, I haven't been able to work on hugulp due to real life :) I'll get back to it at the earliest possible. |
I'd like to be able to turn this off as well. |
I'm currently thinking of a broader change to hugulp. I've never liked the idea of having to install node/npm for these tasks, although the docker instance alleviates the issue. There are some options using go as base and I'm looking into it. I didn't quite catch what you meant with the git info + commit hash. |
Have you looked at Mage for packages? |
Thanks for the suggestion @JHabdas ! I understand you meant https://magefile.org/ It looked great until I read https://magefile.org/howitworks/ Seems you need the go environment in the end user system 😞 |
Yep. Could just like NPM requires Node. Docker is the solve. |
@jbrodriguez Sorry, I was thinking Hugo exposed the last commit for the repo, but it exposed the last commit for individual files. However, what if you did something like this: On the original subject of being able to turn off asset fingerprinting. I think this would make it possible to use hugulp to create themes. I think you could just treat your theme folder like a full site with content and such and then just exclude those folders (content, public, etc) from checkin. I might be missing something, but given hugo's strong separation of file types, I believe it would be possible. |
This is to make sure that you have valid output in static/styles, static/scripts the first time it's run. Ref #20
Could this be made optional without a fork? I use s3_website to deploy my Hugo site and it simply sets cache headers during the CDN deployment, enabling instant cache invalidation without altering the structure of my static files.
The text was updated successfully, but these errors were encountered: