[simonw]

I'm using a Django template tag, {% static "css/example.css" %}

In development, the above tag would output "/static/css/example.css?0.234234" - the random number at the end cache busts so e.g. IE will always load the latest version of the file.

In production, the tag looks up the transformed filename in a dictionary, which looks something like this:

    STATIC_ASSETS = {
        "css/core.css": "css/core.b1b09227.min.css"
    }

The deployment script includes a bit of code that goes through every file in the static directory, figures out the hash, renames it and then writes out that dictionary in a generated static_assets.py file ready to be deployed to the servers. There's a separate management script that pushes the renamed files to S3 - I run that before doing a deploy.

The only really fiddly bit is that the script needs to rewrite all of the CSS files to include the updated filename of any referenced images. I'm using a dumb regex to do this:

    css_url_re = re.compile(r'url\((["\']?)([^)]+?)\1\)')

Since we control the coding standards for our own CSS, there's no need to do anything more robust than that.

[arthur_debert]

On universalsubtitles.org, we're doing something pretty similar to that.

1) Move all static media to a unique hash (we get that from git's commit id, making it trivial to correlate code & static) to /[static-media]/[static-cache]/[git commit uid]/...path to file

2) Set the MEDIA url accordingly

The nice thing about this is that the generated file names are very readable and you always know what changeset generated it just by looking. It's open source if someone finds it useful https://github.com/8planes/mirosubs/tree/master/apps/unisubs...

[mccutchen]

That's a pretty good approach. I guess the main drawback is that the git commit hash will change far more often than the contents of most of the static files, though, right?

[arthur_debert]

Of course, but when in development, we use the a template tag that inserts the original url (no commit hash mangling on MEDIA URL), which means that yes, for each deployment we nuke statics, but on our dev cycle that would happen any way (it's very rare to have a release that does not touch static files), so it's not an issue in practice

[simonw]

We've written our CSS and JavaScript to have a bunch of reusable components, so often we can deploy new features without changing our static assets at all (we reuse classes for components that are already in use elsewhere on the site). I can see how for heavier JS sites this wouldn't be worthwhile though.

[simonw]

That's exactly why we don't use git commit hashes - we only want our users to download new versions when the files have definitely changed.

[mccutchen]

Ahhh, thanks for the details. The only solution I could think of involved writing out a dict like you're describing and using a template helper to look up the modified asset filenames. I was wondering if there was a more elegant solution that was escaping me.

And it probably would've taken me a little while to realize that I'd need to rewrite CSS files as well, so thanks for that, too!

[lamby]

Have you considered rendering your CSS using the templating system? That way {% static .. %} Just Works, and you can also roll extra template tags for repetitive stuff like rounded corners. You can pre-render for the live site, of course.

[simonw]

We thought about it briefly, but it doesn't really fit Nat's preferred way of working with CSS. Might try something like this in the future though.