Durandal Caching Issue / Versioning Strategy

Question

What's a good strategy for versioning Durandal js and html files?

I noticed that, during development, your browser cache must be disabled in order for you to receive up to date files on each refresh. This is a must for during development.

However, my concern is that when I go to production with my continuous deployment strategy (deploying multiple times per day), that users' browsers will be caching older versions of my app which might lead to unpredictable behaviour.

The approach that springs to mind would be to version the js and html urls somehow so that there is a version number embedded into every request. But I am unsure as to how to make that work internally within the Durandal framework.

Alexander Preston · Accepted Answer · 2013-04-29T17:46:39.813

27

Ok, here is the direction that I am heading in. Basically there is something built into requirejs to handle this.

At the top of my main.js, in the call to requirejs.config I can set a urlArgs property that will be appended to every call requirejs makes for a module.

requirejs.config({
    paths: {
        'text': 'durandal/amd/text'
    },
    urlArgs: 'v=1.0.0.0'
});

When I want to force production users to get a new version of the requirejs modules I can just increment the version number which will invalidate the browsers cache.

(In my project I have a way of injecting the version number of the assembly containing my main ASP.NET MVC assembly into this property, but the code for that would have distracted from the simplicity of the above example).

Hope this helps someone!

edited Apr 29 '13 at 17:46

answered Apr 29 '13 at 14:47

Alexander Preston

1,665
11
15

1

Perfect, the type of solution I hoped for too :) – GONeale Apr 30 '13 at 10:55
This doesn't seem to work for me, views/viewmodels still pull up old versions. – ccorrin Jul 06 '13 at 21:09
Do the views and view models being requested have the version number appended to their url? – Alexander Preston Jul 13 '13 at 09:25
Not sure if this would work if you have packaged up the App folder using Gulp or the like, since there would only be one request at the beginning to get the entire html/js – James Reategui Oct 16 '14 at 03:00
That's correct, this approach only works if your durandal app is set to download files asynchronously as your users browse around. A valid scenario on many large sites. – Alexander Preston Oct 17 '14 at 09:42

score 3 · Answer 2 · answered Aug 23 '13 at 18:03

For .NET, add the main-built.js file as a script bundle in App_Start/BundleConfig:

    public static void RegisterBundles(BundleCollection bundles)
    {
        //...
        bundles.Add(new ScriptBundle("~/Scripts/main-built").Include(
                "~/App/main-built.js"));
        //...
    }

Reference the script bundle on your index page:

    @if (HttpContext.Current.IsDebuggingEnabled)
    {
        <script type="text/javascript" src="~/Scripts/require.js" data-main="App/main"></script>
    }
    else 
    { 
        <!-- Remember to run the weyland optimizer to create the main-built.js -->
        @Scripts.Render("~/Scripts/main-built")
    }

As long as you have the default Web.Release.Config file, Visual Studio will automatically remove debug attributes while also minifying and versioning your bundles upon publishing.

Durandal Caching Issue / Versioning Strategy

2 Answers2