Prevent Rails 3.2.11 asset pipeline from caching?

6
votes

I've read a lot of posts and articles and questions & answers on the Rails asset pipeline but I still haven't figured out how to turn off caching altogether.

We're using Rails 3.2.11 and in our Lab environment (similar to development) we're having a problem because even though we are not pre-compiling or fingerprinting assets in the asset pipeline they are still being cached in the Rails (Rack?) cache. This is annoying because some of the assets are ERBs that change based on other configuration so the cache gets stale. In order to try to turn off caching we've set this configuration:

  config.action_controller.perform_caching = false

  config.assets.compress = false

  config.assets.debug = true

  # just in case
  config.cache_store = :file_store, "file_cache"

However, assets are showing up in tmp/cache/assets anyway. I would at least expect them to show up in file_cache, but I really expect them not to be cached at all.

How can we prevent these assets from being cached? Simply deleting the cache is not sufficient in this environment.

Bonus question: as long as these files are being cached, why are they in tmp/ and not in file_cache/?

3
ruby-on-railscachingruby-on-rails-3.2asset-pipeline

3 Answers

8
votes

To turn off the asset cache:

config.assets.cache_store = :null_store

Note that that is config.assets.cache_store not the Rails config.cache_store.

Also note that Sass has a separate cache for compiled stylesheets, by default in tmp/cache/sass, and if you want to disable that you have to do that separately:

config.sass.cache = false

To answer the bonus question, when the Rails Guide says:

The default Rails cache store will be used by Sprockets to cache assets in development and production.

I thought they meant the configured Rails cache store would be used. I was wrong, it uses the default cache unless you explicitly change the asset cache.

-1
votes

To completely disable assets pipeline, you can add this directive in your environment file:

config.assets.enabled = false

But if you still want to enjoy assets pipeline compilation and caching for your static JS and CSS, and at the same time use ERB files for dynamic assets, you could create a my_assets_controller and create views for that controller that deliver dynamic content (files with extensions .css.erb and .js.erb). You just have to include in your view or layout file <%= javascript_path '/my_assets/things_dynamically_generated.js' %>

-1
votes

This sounds like an XY Problem.

Principle 1: The build must be deterministic and independent of per-environment configuration.

Principle 2: The static assets compilation must be part of the build.

You should move toward having purely static assets. You can use ERBs, but just to call methods like asset_path, which are deterministic and which produce the same result given the same codebase. You can put configuration-based data or behavior in there, but only if the data or behavior is the same across all deployments (dev, test, staging, qa, pre-prod, and prod).

Anything that comes from the per-environment configuration should not find its way into the static assets. Instead, you can deliver that in HTTP headers, attributes on the <html> element, or other injection techniques. The static assets code should be smart enough to look for the injected data in the HTTP headers or <html> attributes and alter its behavior based on that injected data.

As for the bonus question, config.cache_store is not the controlling configuration item for the sprockets, sass, compass, etc caches.