Rails compiles assets both with and without md5 hash, why?
Asked Answered
Q

1

15

I'm relatively new to RoR and I'm curious about why Rails compiles assets both with and without md5 hash for production?

I run bundle exec rake assets:clean then bundle exec rake assets:precompile

My production.rb file:

MyApp::Application.configure do

  # Code is not reloaded between requests

  config.cache_classes = true

  # Full error reports are disabled and caching is turned on

  config.consider_all_requests_local       = false

  config.action_controller.perform_caching = true

  # Disable Rails's static asset server (Apache or nginx will already do this)

  config.serve_static_assets = false

  # Compress JavaScripts and CSS

  config.assets.compress = true

  # Don't fallback to assets pipeline if a precompiled asset is missed

  config.assets.compile = false

  # Generate digests for assets URLs

  config.assets.digest = true 

  config.action_dispatch.x_sendfile_header = 'X-Accel-Redirect' # for nginx

  config.assets.precompile += %w(tos.js, tos.css)

  config.i18n.fallbacks = true

  config.active_support.deprecation = :notify

end

My application works with files with hashes in their names and it's the way it should be in my case :)

So I have two questions here:

1) Why is it happening when compiled?

Rails compiles assets both with and without md5 hash for production

2) What are these files (without hashes) for?

Maybe I don't get something, so please could someone explain.

Quasijudicial answered 6/4, 2012 at 15:52 Comment(0)
I
15

The reason it does it is so that you can access the files without knowing the MD5 fingerprint (for example in a non-rails application, or a file within the rails app which isn't compiled or run by the rails stack (e.g. a 500/502 status error page). In this case you would have to compile the assets then change the css/js links in the static HTML files each time you updated the code (thus causing a change in the MD5 hash).

So instead rails produces 2 copies of each asset file, one with the fingerprint in the filename, the other without (e.g. application-731bc240b0e8dbe7f2e6783811d2151a.css, and application.css). The fingerprinted version is obviously preferred (see 'what is fingerprinting and why should I care' in the rails asset pipeline guide). But the non-digested version is there as a fallback.

As a final thought on the matter I'd take a read of the following pull request to the rails git repo: https://github.com/rails/rails/pull/5379 where they are discussing the pros and cons of the non-digested filenames, and the possibility of being able to turn off compilation of them.

HTH

Illbred answered 6/4, 2012 at 16:40 Comment(3)
Hello Chris thank you for your reply and explanation, I thought that I've got some misconfiguration that caused this behavior. If this the way it should be then it's ok with me. Thanks again.Quasijudicial
On the flip side of things, my Rails installation has the exact same configuration as his, but it's ONLY compiles assets with the fingerprint, and is not compiling the versions without the fingerprint. This is very annoying for the reasons listed by Chris Bailey. Any idea how I can fix this?Blackwell
@NudeCanalTroll: You're not running rake assets:precompile:nondigest.Appetency

© 2022 - 2024 — McMap. All rights reserved.