Rails.application.assets is nil in production

[kirs]

Now in sprockets-rails 3 app.assets is set only in case when assets.compile option is enabled (https://github.com/rails/sprockets-rails/blob/master/lib/sprockets/railtie.rb#L142).

By default in Rails this option is set to false in production environment: https://github.com/rails/rails/blob/master/railties/lib/rails/generators/rails/app/templates/config/environments/production.rb.tt#L27

This leads us to the bug when some gem calls Rails.application.assets.resolve("asset.js") in production environment and the NoMethodError is raised.

@josh does it sounds like a bug?

[josh]

Thats right.

assets.compile = false is supposed to completely disable asset compilation. This prevents inadvertent calls to sprockets in production.

So it sounds like using those gems may have been behaving poorly in production before.

[rafaelfranca]

Yeah. That looks right to me too.

@kirs do you know why the gem is doing that?

[kirs]

@rafaelfranca that is react-rails, for instance: https://github.com/reactjs/react-rails/blob/master/lib/react/rails/railtie.rb#L15

They do it inside lambda, but it's still being called in production with application.assets is nil.

[matthewd]

ISTM the ideal would be for us to provide an application.assets that knows how to look things up from the manifest, without doing any new compilation.

That way we could help people ignore implementation details (that, IMO, they shouldn't need to care about) like where on the filesystem the assets actually live -- basically providing a more-suitably-shaped API around just using File.read.

[josh]

It seems like this is being fixed on the react-rails side.

[matfiz]

Just as the reference for people trying to fix it in the local codebase after the update. The easy fix is to replace Rails.application.assets.find_asset("#{asset_name}") with Rails.application.assets_manifest.files.values.map{|v| v['logical_path']}.include?('#{asset_name}')

[Grammarella]

matfiz, thank you very much for the helpful workaround.

[matheusvetor]

Hello, my approach is different. I need to use compiled asset inline on production.
My layout uses all content inline. I need to use this way because i have a ruby client which get the html and shows on Raspberry PI.

doctype html
html lang="pt"
  head
    meta charset="utf-8"

  css:
    #{App::Application.assets["static.css"].to_s.html_safe}


  body
    header
      .top.full.left
        img(src="data:image/png;base64, #{@title_news_encoded}" class="margin-title-news left")
        img(src="data:image/png;base64, #{@text_encoded}" class="margin-text-news left")

        img(src="data:image/png;base64, #{@logo_big_encoded}" class="margin-logo-news right")
    section
      = yield

On my old Rails 4.2 app this works fine in both development and production. On my new Rails 5 app this only works on development.
Now on development App::Application.assets["static.css"] returns a Sprockets::Asset.

An additional information: My new App runs on Heroku

[matheusvetor]

I got to work with the following code

css:
  #{File.read("#{Rails.root}/public/assets/#{Rails.application.assets_manifest.files.collect{|k, v| k if v['logical_path'] == 'article.css' }.compact.first}").html_safe}

It is very ugly but for now was I could think

[fxtentacle]

Thanks @rafaelfranca. Rails.application.assets_manifest.find_sources('asset.js').first seems to return exactly what Rails.application.assets['asset.js'].to_s used to produce and it works both in dev and prod :)

[rafaelfranca]

And doesn't compile the asset in production.

[hoanghuynh]

Thanks @rafaelfranca @fxtentacle that works for me!

[allenmackley]

@fxtentacle your solution worked great for me, thanks.

I had to modify it slightly by putting html_safe to this line:
return asse.to_s.html_safe if asse

And then in production.rb

config.assets.compile = true
config.assets.css_compressor = :sass

[nasa42]

If you are looking for an exact replacement for asset = Rails.application.assets.find_asset(name), (i.e., a method that returns a Sprockets::Asset object, so that you can have access to methods like content_type), use asset = Rails.application.assets_manifest.find(name).first.

[nzifnab]

@nasa42 Rails.application.assets_manifest.find(name).first gives the error:

"Sprockets::Error: manifest requires environment for compilation" which makes it sound like it's trying to recompile...

[nasa42]

@nzifnab Sorry, we are no longer using that line in our app, so I don't have any more information about it.

[grosser]

FYI I needed to find files that are not part of the manifest ... so switching to looking through gem dirs instead:

# clunky asset finder ... see https://github.com/rails/sprockets-rails/issues/237 for more
# jquery.js -> <GEM_HOME>/ruby/2.3.0/gems/rails-assets-jquery-2.2.1/app/assets/javascripts/jquery.js
def resolve_javascript(file)
  paths = Gem::Specification.stubs.map(&:full_gem_path)
  Dir.glob("{#{paths.join(",")}}/app/assets/javascripts/#{file}").first || raise("Could not find #{file}")
end

[mrsimo]

We needed to access a compiled file within another file during precompilation, so Rails.application.assets_manifest didn't work the first time you run assets:precompile.

We solved this by doing this:

Sprockets::Railtie.build_environment(Rails.application, true)[file_name].to_s

In case anyone is in the same situation that we are.

[tom-brown]

I found ways to check for assets in both development and production (heroku) in Rails 5.2, but neither works in both environments, so I added an application helper like this:

def image_exists?(path)
    if Rails.env == "development" && Rails.application.assets.find_asset(path)
      return true
    elsif Rails.env == "production" && Rails.application.assets_manifest.assets[path]
      return true
    else
      return false
    end
 end

Now I can check if an image_exists in both production and development before calling image_tag. The root of the problem is image_tag throws an exception if the image doesn't exist....why not just respond nil???