sprockets-rails: Changing version does not bust cache
This only happens in combination with sprockets v3 (tested with 3.0.1 and 3.0.2). Changing the version config does not result in different digests for the individual assets.
How to reproduce:
gem install rails
rails new foobar
cd foobar
rake assets:precompile
ls public/assets > assets1.txt
tr "'1.0'" "'2.0'" < config/initializers/assets.rb | tee config/initializers/assets.rb
rake assets:precompile
ls public/assets > assets2.txt
[[ -z "$(diff assets*.txt)" ]] && echo "no diff" || echo "diff"
Notice how the file names are the same between the two version configs.
Adding gem 'sprockets', '< 3' to the Gemfile and repeating the steps above results in different file names, as expected.
About this issue
- Original URL
- State: closed
- Created 9 years ago
- Reactions: 3
- Comments: 34 (9 by maintainers)
Also lost +1 hour on this today.
Just want to point that I’m on Rails 5.2, which defaults to sprockets 3.7.1, and this bug still occurs.
As far as I could see, there’s an open pull-request https://github.com/rails/sprockets/pull/478 to backport this to sprockets 3.7, since the merge mentioned in https://github.com/rails/sprockets/pull/404 was for version 4 only, which Rails 5.2. still doesn’t use.
Considering a brand new Rails 5.2 app has the following line in
config/assets.rb:# Version of your assets, change this if you want to expire all your assets.And changing that version number does nothing, I consider this to be an open bug and maybe this could be reopened.
@rafaelfranca could you please reconsider?
I’ve been pulling my hair out for a couple of hours over this. I have assets cached in a CDN with incorrect
Access-Control-Allow-Originheaders so I need to invalidate them all. As mentioned here changing the version doesn’t alter the filename so the CDN continues to serve the stale responses.The change introduced in Sprockets 3 appears to leave no way to expire all assets, which is contrary to the expected behaviour and the comment included in new rails projects:
@lime yes. It doesn’t need to be opt-in, we are fine to restore the previous behavior.
I’m also interested with the outcome of this issue. Is there an update?
👍 for option 1 — changing
config.assets.versiondoesn’t happen that often, but when it does, busting cache is its main purpose.Option 2 is bad practice (as outlined in Rails’ guide) and messing with
config.assets.prefixseems like a hack.So how can I bust the cache if the file name is still the same? The client will just use the file from a previous request. Wasn’t that the whole point of the version config, to change all asset file names and thus bust the cache?