Make asset pipeline act like production on development

Question

I am experiencing some problems with assets on production: missing ones, stuff compiled into the wrong files (javascript for "/admin" getting compiled into the frontend code and so on). Most of the assets come from engines. I want to debug and optimize this.

For that, I need to precompile, serve and fail on my development environment just like it is done on production.

I have added some lines to my config/development.rb:

  config.serve_static_assets = true
  config.assets.precompile += %w( store/all.js store/all.css admin/all.js admin/all.css ) # @TODO: clean up, and optimize.
  config.assets.compile = false

Running this with rake RAILS_GROUPS=assets RAILS_ENV=development assets:precompile gives me all the assets and the manifest.yml in public/.

But then the server fails:

Sprockets::Helpers::RailsHelper::AssetPaths::AssetNotPrecompiledError in Spree/home#index

Showing /xxxx/app/views/spree/shared/_head.html.erb where line #13 raised:

favicon.ico isn't precompiled

favicon.ico isn't precompiled. But it is! Its there, in the public dir, in manifest.yml, and I can fetch it with the browser (or wget): http://localhost:3000/assets/favicon.ico.

NOTE Favicon is simply the first asset called. If I strip out favicon, the problem simply surfaces with the next asset, being "all.js", or, when that is stripped, "all.css", and so on. I can strip it untill "footer_bg.png", and it will then fail there. Again: the problem is not favicon, but the fact that the development environment does not see the precompiled assets at all.

What more is needed to get development asset pipeline similar to production?

EDIT: More explicit explanation that favicon is not the problem, merely a symptom.

Answer 1

I ended up installing an apache, passenger on localhost to troubleshoot.

Apache (could probably be any passenger-able server) because of the static asset serving. Furthermore, on localhost I can bump the verbosity of apache in its logs very high, offering me enough debug information.

Passenger to emulate the ruby version and the gem-loading as much as possible as on production.

Running on webrick is just too different, even when emulating as close as possible, it proved too different from a production stack; which is why I could not reproduce the production problems in there,

Firing up the whole stack as if it were production allowed me to troubleshoot. Which lead me to conclude that several problems were causing the asset-woes: a gems assets not being picked up; a permission issue (compiled assets not readable by www-data) and a few assets not being compiled properly.