Sprockets 3 doesn't provide gz file anymore (gzip compression)

[charlesdg]

As mentioned in Sprockets 3 commit (sstephenson/sprockets@d388ef7), Sprockets 3 doesn't provide gzip file anymore.

Then, if gzip compression is activated for asset sync, the upload_file method of the file storage.rb (https://github.com/rumblelabs/asset_sync/blob/master/lib/asset_sync/storage.rb) will not do its job anymore since the gz file are not compiled by Sprockets 3.

For now, I came back to sprockets 2.12.3 and everything goes fine.

[BrokenChair]

I'm having the same problem. Is there any other workaround besides reverting to an older version of sprockets?

Perhaps the rake task could be enhanced to create the gzip versions for every css/js file?

[mirzali]

+1

[mirzali]

as a temporary patch, you can gzip the assets manually:

in config/initializers/asset_sync.rb

config.run_on_precompile = false

and then have a rake task named "assets:deploy"

namespace :assets do

  task 'deploy' => [:environment] do
    %x{
      RAILS_ENV=production UPLOAD_ASSETS=true RAILS_GROUPS=assets bundle exec rake assets:clobber assets:precompile assets:gzip assets:sync
    }
  end

  task 'gzip' => [:environment] do
    require 'zlib'

    Dir['public/assets/**/*.{js,css}'].each do |path|

      Zlib::GzipWriter.open("#{path}.gz") do |gz|
        gz.mtime = File.mtime(path)
        gz.orig_name = path
        gz.write(IO.binread(path))
      end

    end

  end

end

warning: you may need to clear the remote folder, because the gem will see the files as already uploaded and ignore them

[masterkain]

Not really battle tested but this seems to be working for us without modifying our config:

# lib/tasks/asset_sync.rake

namespace :assets do
  task :gzip do
    require 'zlib'

    Dir['public/assets/**/*.{js,css}'].each do |path|
      gz_path = "#{path}.gz"
      next if File.exist?(gz_path)

      Zlib::GzipWriter.open(gz_path) do |gz|
        gz.mtime = File.mtime(path)
        gz.orig_name = path
        gz.write(IO.binread(path))
      end
    end
  end

  desc 'Synchronize assets to remote (assumes assets are already compiled)'
  task :sync => [:environment, :gzip] do
    AssetSync.sync
  end
end

[shawndeprey]

@masterkain & @mirzali Is there any way to hook these two tasks into rake assets:precompile? Maybe using something like rake hooks? https://github.com/guillermo/rake-hooks

[shawndeprey]

As an aside, I also moved back to sprockets 2.12.3. I am not sure what adverse effects this will have given that I am using Rails 4.2 but I will keep testing. If we can tie the above solution into precompiling it will be a better solution.

[mirzali]

I think @masterkain solution already solves that. As for using sprockets 2.12, I believe you should be all right, since I'm in a similar situation as well.

[cweilemann]

@shawndeprey I'm running into this exact situation, and just downgraded sprockets. I'm still not seeing my assets gzipped on S3. Was there anything else you needed to do?

[shawndeprey]

@cweilemann negative, I just downgraded and the previous process that worked just worked again. The version you downgraded to actually overwrites the static files with the gzip version per sprockets docs. Check out the file size, that threw me off at first too since it used to create a completely seperate file.

[pierrebeitz]

@shawndeprey As rake does not override but chain tasks, you could declare those tasks assets:precompile to transparently gzip and sync after actual precompilation. So this should be a solution working with sprockets 3:

namespace :assets do
  # We make use of rake's behaviour and chain this after rails' assets:precompile.
  desc 'Gzip assets after rails has finished precompilation'
  task :precompile do
    require 'zlib'
    Dir['public/assets/**/*.{js,css}'].each do |path|
      gz_path = "#{path}.gz"
      next if File.exist?(gz_path)

      Zlib::GzipWriter.open(gz_path) do |gz|
        gz.mtime = File.mtime(path)
        gz.orig_name = path
        gz.write(IO.binread(path))
      end
    end
  end
end

[seanhealy]

We also had this issue with Sprockets 3. @pierrebeitz's fix seems to be working for us.