Update comment in offline_asset_paths.rb for newer versions of Rails

[kevinburkeomg]

The comment describes what I want to do, but the code example does not work for recent versions of Rails.

# Rails Asset Patch extension used to write assets out an offline asset directory
# for future use
# example:
#   ActionView::AssetPaths.send :include, JasmineRails::OfflineAssetPaths

It looks like that ActionView::AssetPaths was removed after Rails 3. I'm hunting around in the docs to try to figure out what the replacement was/is.

[kevinburkeomg]

Basically I would like to compile assets to tmp/jasmine ahead of time. Alternatively it looks like Jasmine assets are getting compiled to public/assets - would it work to set Jasmine's tmp_dir in my config to public/assets? I feel nervous about doing that because I worry it might remove files that exist in that directory.

(sorry, I am new to Rails)

[kevinburkeomg]

I've messed around with this a lot, and I can get JasmineRails to compile its css/js etc. to my public/assets folder from a Rake task, with RAILS_ENV=test. However, that doesn't help much because it compiles again to tmp/assets when I run rake spec:javascript.

Here's my rough working code for getting it to compile to public/assets:

require 'jasmine-rails'
require 'jasmine_rails/offline_asset_paths'
require "jasmine_rails/engine"
JasmineRails::OfflineAssetPaths.disabled = false
ActionView::Base.send :prepend, JasmineRails::OfflineAssetPaths

However when I call Rake::Task['assets:precompile'].invoke, compute_asset_path never gets called.

[kevinburkeomg]

Ah, it turns out when I compile to public/assets, Sprockets has some trick where it can copy from there to tmp/jasmine/assets very quickly (I think). jasmine-rails still indicates some compilation is going on, but it completes in 1.2 seconds, instead of 80, so that's an improvement.

[kevinburke]

So yeah the reason that I was looking for this hack was that I was confused why jasmine-rails needed to recompile assets when it booted. It turns out I was unaware of the Sprockets asset cache, which existed on the machine sometimes and didn't exist other times (it's a build server).

Ensuring the Sprockets asset cache existed in every case gives me reliable behavior now, and I don't need this workaround. (We could probably still update the comment)