reason
Offers a simple mechanism to allow extremely long expire-headers on scripts whilst still being able to switch to newer versions on the fly.
implementation
A js file defined with data-main attribute on the script tag of require.js, will always be loaded with current timestamp to always force a fresh load.
// main.js?cacheKey=TIMESTAMP-123412312321
<script data-main="main" src="require.js"></script>
Inside main.js you can define a cacheKey that will be appended to all loaded scripts from that point on.
// results in [root]/module.js?cacheKey=v1.0.0
require.cacheKey( "v1.0.0" );
require( "module" , function( module ){
/* code*/}
);
or using RequireJS config mechanism:
// results in [root]/module.js?cacheKey=v1.0.0
require( {
cacheKey: "v1.0.0"
} , "module" , function( module ){
/* code*/}
);
Set extreme long expire headers on .js files and you get optimal browser caching whilst able to update an entire dependency tree by setting one value.
As an alternative to setting the cacheKey variable in javascript, it could also be passed by another data- attribute. (from Smith, see comments)
<script data-main="main" data-cacheKey="v1.0.0" src="require.js"></script>
This allows both development teams (backend/frontend) to be able to control the cacheKey. However a question of what overrides what remains.
As a bonus, you could opt to override cacheKey usage with a path-expression plugin (see path-expression gist).
// not a pretty path-expression I admit.
require( "module !nocachekey" , function( module ){
/* code*/}
);
Good addition, will update the gist, thanks Smith ;)
However, you only need to update the cacheKey whenever a javascript dependency changes and it's maintenance is more appropriate to fall under your javascript/frontend devs, I mean they have direct access to main.js. Then there's the question of double definition, perhaps an error or warning should be thrown when the cacheKey is defined both ways?