search

benhoIIand / grunt-cache-bust

Cache bust static assets using content hashing
MIT License
265 stars 103 forks source link

Option hash - why its not listed? #175

Closed ricardohbin closed 8 years ago

ricardohbin commented 8 years ago

Since old versions, there's a very useful option, called .hash (in actual version it is inside utils.generateFileHash).

It can be used to force your own hash, that can be the git version, the build timestamp, etc.

Why its not listed as option to cache bust task? Do you intend to remove it in next versions?

benhoIIand commented 8 years ago

Hi @ricardohbin - not the first time I've been asked this recently.

My plans are to remove the ability to set your own hash as it's not inline with what this plugin should be doing. It's purpose is to generate a hash value based on the contents of the file. This means that when a user hits your website again, they aren't forced to download a new version of all the files, just the ones that contain changes.

What value does using a git version or build timestamp give? If it's for developers to see what version is currently in production, there's different ways of checking that.

Edit: If the demand for the functionality is there, it can be left in. I'd like the plugin to promote best practices as much as possible

ricardohbin commented 8 years ago

Hi @hollandben , thanks for fast reply.

In some big projects, that have a lot of cache layers (like akamai + varnish + nginx microcache etc etc), it can be good to avoid inconsistencies in production. In some contexts, the fact of users re-download the same content isn't a real problem.

It could be useful too to manage the versions of your assets if you use package builds and want some some kind of control in storage buckets like S3/ceph etc.

Just some thoughts, but in some complex assets lifecycle (like that enormous CI pipelines etc etc) this feature can be very good.

In my case, it will :P

benhoIIand commented 8 years ago

Even with multiple layers of caching, I don't see why you'd want to invalidate a cached item when it hasn't changed.

That being said, I will consider leaving that functionality in the plugin and document it with the above explanation - it should promote best practices but not restrict users.

benhoIIand commented 8 years ago

I've left the hash option in the feature/v1.0.0-beta branch. I'll be link to some documentation specifying why, in most cases, it shouldn't be used though

ricardohbin commented 8 years ago

@hollandben surely, I got your point of view, it can be hard to figure out why someone want to invalidate a cache that hasn't changed.

But the real problem is the sync between the templates/assets and storage. And cache buster is used to bypass the cache, getting a MISS. I already see situations that the original file didn't "ready" when the template with new hash MISS it, so the file cached in CDN was the old one, and not the new one (even with the new hash). And it's just a example, I already see some strange situations :package: