Hashing before changing references

[imorrison]

I am having a somewhat difficult issue with a project that employs usemin, related to the ordering of the grunt-usemin task.

Let me try my best to explain: usemin hashes files before it replaces urls. This means that the hash is not entirely accurate. If you where to change the urls in a file and then hash it, you would get a different result. This means that if file A has a reference to file B and only file B changes, the hashes will get out of sync because only the reference to file B has changed in file A and the hash will remain the same. If your server configuration has aggressive caching, it will continue to server the file with the incorrect reference - this is because hashing occurs before the references are changed.

Let me outline the steps again:

1. Nothing changes with file A. It contains a reference to file B.
2. File B changes and therefore its hash changes.
3. File A gets an updated hash for file B; however, its hash does not change
4. Because of caching, the older version of File A, with the previews hash for file B, is still live

I am not entirely sure what the best approach to solving this problem is. A co-worker suggested building a tree of dependancies, and topologically sorting it, before hashing the contents. Another co-working suggested a more 'brute force' solution that would continue hashing the files until none of the file hashes change.

I would like to know if other people are experiencing this problem. There may be a tried and true solutions to this that I am not aware of.

[markrian]

I've encountered this issue as well, and have only just begun exploring solutions/workarounds. This issue pretty much breaks the whole point of asset hashing, since, to use your example, file A's contents change (due to the different reference to B), but its name stays the same. Did you ever find a reasonable solution, @imorrison?

The tree of dependencies sounds like the most correct solution (would need to check for circular references, too), but probably requires a fair amount of work in filerev and usemin. In fact, filerev and usemin are designed to be independent and single-pass, whereas this would require them to be more coupled...

[amithalb]

+1
I'm thinking of avoiding the problem by removing all file references to a single "routing" module, which holds the latest references to revved files and is configured not to be cached by the server.
...Would be happy not to do that.

Any other ideas? anyone?

[markrian]

I ended up writing a grunt task called vermin which repeatedly runs filerev and usemin until the filenames stop changing, i.e., the 'brute-force' method. It does the job for me, and doesn't increase the build time much at all since filerev and usemin are relatively quick, although YMMV.

It makes lots of assumptions, which you can read about in the gist. Comments/improvements welcome!

[amithalb]

Thanks @markrian - works for me!