Yui invalidate javascript browser cache with new release - maven

Question

I have YUI project that is mavenized. When we release new YUI code, it is not reflected right away in the browser, until you do SHIFT + REFRESH on browser.
I have been using YUI modules approach to load scripts like this:
YUI.GlobalConfig = {
modules: {
'manual-entry-util': {
fullpath: 'resources/js/common.js',
requires: [ 'node']
},
'user-perm-util' : {
fullpath: 'resources/js/userPermUtil.js',
requires: [ 'node', 'io-base', 'json', 'json-stringify']
},
'file-upload-custom' : {
fullpath: 'resources/js/fileUploadCustom.js',
requires: [ 'gallery-datatable-selection','event-custom', 'node']
},
'icsd-uploader' : {
fullpath: 'resources/js/icsdUploader.js',
requires: [ 'uploader', 'node']
},
'ui-util' : {
fullpath: 'resources/js/uiUtil.js',
requires: [ 'node']
}
}
};
I believe we need to modify the urls to have some sort of variable so that new code can be picked up by the browser.
Is there a way to automate this process via maven or some other tool. E.g. which can generate the hash value from the contents of the .js file and then add that to the url of .js file?

Answer 1

My approach has been to include a cache-busting value at the beginning of the path to your resources. An appropriate value might be the current abbreviated commit hash or revision number, or if using a CI tool, the current build number. Your build process would deploy all of your assets into a directory named with this value, so if your current commit hash was abcd1234, you would end up with files in something like resources/abcd1234/js/.
Your build process would need to also dynamically modify your YUI.GlobalConfig object, perhaps using token replacements, so that the YUI Loader could find your files there. This could be done in one spot by setting the base configuration option (see http://yuilibrary.com/yui/docs/yui/loader.html#configuration-options), but since you're specifying the fullpath for each file, you'd have to set each of these.
During development, you'd have to continue hard reloading your pages (as you're doing now with SHIFT + REFRESH), but your users will cache each version of your resources separately.

Answer 2

We use a variant of the answer from #blicksky. We built our own combo-loader as a servlet.
Firstly, we set up YUI as it's own Maven project. The version tag reflects the release of YUI, so your version would look like <version>3.17.2</version. We have an in-house repo, so any update to the YUI project gets published there. The YUI project just houses a copy of YUI in /src/main/resources/META-INF/resources. In this respect it's pretty similar to the approach taken by the WebJars project.
The Combo-loader takes care of concatenating the YUI files together for better loading performance and is also responsible for adding a cache-busting URL parameter. In production that parameter is the Build ID, but in development, that parameter can be a random number, so that the resources are loaded each time. We're using Spring on the server, so we use the Classpath to resolve YUI files that come from the YUI Maven project mentioned above. The basic gist is that our Servlet implements ResourceLoaderAware and can then use the ResourceLoader to pick up YUI files to serve up.
The approach has served us well and also allows us pretty fine-grained control of how the files are served, as well as improving load-times.