Prefix compiled assets with SHA hash to prevent cache issues about asset-pipeline

[evantishuk]

Just curious if a prefix is better than a suffix for some technical reason?

If not, I think it's marginally more readable (assuming a left-to-right reading convention) to use a suffix.

assets/application.js?v=f1aede3b6c or assets/application.f1aede3b6c.js

[modbase]

No, there's no technical reason for this. That's just how Yeoman handles it, so I simply took over their convention.

The type of versioning (querystring or filename) could be a configuration option, but I wouldn't use querystring by default.

[evantishuk]

Either way, I agree this should be a feature. Good call.

[kdocki]

Are you suggesting we write out files to public/assets/ i.e. public/assets/foobar.f1aede3b5c.js.coffee on all environments?

[modbase]

No, not on all environments. Only when in production when the assets are minified and concatenated, just like Rails does by default.

It would even be better to be able to separate the vendor and the app JavaScript, i. e. public/assets/vendor.f1aede3b6c.js and public/assets/application.5d3250e678.js. This will prevent users to redownload all vendor assets when only a small change was made in the custom JavaScript.

[evantishuk]

Just wanted to chime in and point out that Assetic also provides some cache-busting features that might be worth leveraging: https://github.com/kriswallsmith/assetic#cache-busting

[niallobrien]

Any update?

[niallobrien]

Still no update guys?

[kdocki]

@niallobrien, @modbase, @evantishuk please see the other issue #34 for a proposal ... I'm closing this as it all ties together in how things should be cached for performance really. I think it would be good for everyone to come to some sort of conclusion on how we expect things to be cached. There is a rudimentary system in place for caching right now but it could be enhanced in my opinion.