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.