8
votes

I'm just getting acquainted with Rails 3.1, and I burned some time updating an old project and trying to work out how the new asset pipeline behaves in development mode versus production.

The default config.assets.precompile setting blesses only application.css and application.js, with the intention that everything should be served as a single stylesheet and a single javascript file.

Obviously there are situations when we don't want that, so we can add items to the list in that config variable...

Here's the situation I ran into with my sandbox project when going to production:

  1. Browsed the site in development, saw that everything was working. The assets were linked as separate files and the site displayed correctly.
  2. Uploaded the site to my server, and tried to get it working in production. The first error was saying that "ie.css" (a conditional stylesheet) isn't precompiled. (I was in Safari and this stylesheet wouldn't even be downloaded: the error was raised from the stylesheet_link_tag helper before rendering the page.)
  3. Ran rake assets:precompile and tried again.
  4. Added the offending item to config.assets.precompile and tried again.
  5. Kicked the error down the curb until it hit another asset error.
  6. GOTO 3.

Not knowing how to address this, I went around in circles a few times until I thought I got all the assets and the site was rendering in production. Then I tried it in MSIE and hit another error 500: "belated_png_fix.js" was being conditionally loaded, and it didn't crop up until then.

So my question is, other than trial and error or a heavy dependence on integration testing, how can I predict that my site isn't going to bomb out when the asset pipeline discovers that some stylesheet or javascript wasn't added to the precompile list?

I'm also curious why a missing stylesheet asset should cause the whole page to error 500 instead of just compiling it on-demand or serving a 404 when that asset is requested. Is this a deliberate design to "fail early"?

4
I recently converted an old app to the asset pipeline and had no problems. It took me a while to figure out how everything worked together though. To answer your question, can you show the contents of your css and js files, specifically the require statements? I am also interested in how you are calling these from the view. Lastly are they all in app/assets or are you using lib/assets and vendor/assets as well?Joost Baaij

4 Answers

2
votes

I've just released a gem called assets_precompile_enforcer, which ensures that developers won't forget to add assets to config.assets.precompile while they are developing. An exception will be raised if you include an asset via javascript_include_tag or stylesheet_link_tag, and it doesn't match a filter in config.assets.precompile.

This means that asset errors will be caught during development, instead of being discovered after deploying to production.

1
votes

I had similar problems with rails 3.1 as well. The best thing you could do is to install capistrano multi stage and get a staging server.

If for any reasons this is not possible, install a virtual machine on your computer and try to replicate your servers environment.

1
votes

Continuous deployment is a great thing, and you should get to the point where it is so simple that it really isn't that painful anyway. That being said, config.assets.precompile can take regexs, so how about you come up with a standard for top level sprockets "manifest" files, or a standard sub folder for things that will not be bundled up? (note that I haven't actually tried this yet...)

0
votes

This may be overkill, but this works for me (it gives me clean, compiled assets). I have this in my .bash_profile file.

alias ggo='bundle exec rake assets:clean && bundle exec rake assets:precompile && git add . && git commit -m "precompile" && git push origin master && cap deploy'

and this in my config/environments/production.rb (forces production to compile when needed; shouldn't be a need to if I remember to run "ggo" first):

  config.assets.compile = true

So, my workflow is: 1. code 2. git add & git commit 3. if I touched CSS/SASS/JS/CoffeeScript files, I run ggo. Otherwise, I do a normal cap deploy.