https://github.com/rails/sprockets-rails/issues/49 (which is locked so no further discussion is possible there) debates whether asset precompile should create a non-digest version of the assets.
There are a few valid use cases for this, and I do not have solutions for all of them, but I just thought of a solution to one--static error pages. @pelargir, in some of the first comments on the issue (https://github.com/rails/sprockets-rails/issues/49#issuecomment-20529994, https://github.com/rails/sprockets-rails/issues/49#issuecomment-20531267), stated the issue: > Removing generation of non-digest files also makes is impossible to have static 404 error pages that use the same images, JS, and CSS as the remainder of the site (without making duplicate non-digest copies of those files in /public). But then I end up with two copies of the same file in my app. > Am I supposed to copy the precompiled file into /public and remove the fingerprint from the filename? So then, if I change the file in the future, I have to precompile, copy, and rename all over again? My idea is to make the static error pages part of the asset pipeline. Instead of generating public/500.html, public/404.html, etc, a new rails app should generate app/assets/html/500.en.html.erb, app/assets/html/404.en.html.erb, etc. "app/assets/html/*" should by default be included in config.assets.precompile (which I believe it is anyway since it's in app/assets and the extension is neither .css or .js). There are 2 places where the behavior would be significantly different than of all other assets, so things would get a little tricky here: 1) Unlike other assets, these would need to be precompiled in the context of a layout. This could be either the same application layout as the rest of the application (app/views/layouts/application.html.erb ), or the "rails new" generator could create a separate app/assets/html/error_layout.en.html.erb (which itself should be excluded from precompiled). Telling sprockets when to compile in the context of a layout could be tricky, but an alternative is just to code that into the view. Below is an example from an existing project of mine. It's in HAML, not ERB, but still illustrates the point: # app/assets/html/500.en.html - layout = Rails.root.join("app", "assets", "html", "error_layout.en.haml") = Haml::Engine.new(File.read layout).render do %h5 We're sorry, but something went wrong. %p Our developers are working on it. 2) Error pages currently live in public, but with this approach, they would end up in public/assets, and would have digests in their file names. So we would need to change https://github.com/rails/rails/blob/v4.2.3/actionpack/lib/action_dispatch/middleware/public_exceptions.rb#L44 to look in "public/assets" and use the appropriate digests, and add a Depracation warning (that shows up in development environment) if the error pages are found in "public". -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
