I'm looking to get some more feedback on an issue (and fix) I posted here: Asset digest fingerprinting should be a config option · Issue #2294 · rails/rails · GitHub.
TLDR; asset fingerprinting causes issues in production mode with certain javascript libraries due to dynamic file loading. Notably the major editors (TinyMCE, CKEditor, etc) but smaller libraries can be affected too. My fix allows for certain paths to be excluded from fingerprinting or for fingerprinting to be disabled altogether.
An example; let's say I'm building an app and I want to integrate FancyZoom (GitHub - jnunemaker/fancy-zoom: [DEAD] Zoomy JavaScript based loosely on Fancy Zoom by Cabel Sasser.). I copy the files into my assets folders (either app/assets or vendor/assets) and require the javascript in my application.js.
Everything works fine in development mode, but the images won't load in production, due to the fingerprints appended to the image filenames. Using the image-url helpers won't help here either - check the code (fancy-zoom/jquery at master · jnunemaker/fancy-zoom · GitHub js/fancyzoom.js) and you'll see why.
At this point, I am forced to move the assets into public. I either move all of the FancyZoom assets together, giving up on including the library's javascript in my application.js, or I move only the image files into public.
Either way, assets are now spread between public and app/assets. I also now have assets located at http://mysite.com/assets as well as http://mysite.com/fancyzoom. Messy.
Or, if my patches are applied, I add to my config/application.rb:
config.assets.fingerprinting.exclude << "fancyzoom/*"
and I don't need to do anything else. As seen in my proof of concept (https://github.com/spohlenz/tinymce-rails/blob/master/lib/tinymce- rails.rb), gems with assets can do this automatically. The app developer doesn't need to know about it, it just works.
In my opinion, this is a critical feature to make the asset pipeline workable. My fix does add some extra options to the Sprockets environment but I haven't seen a better way of doing it yet.
Thanks, Sam Pohlenz
