Rails 3.1, Asset Pipeline, Sass Syntax & Heroku

Oct 01 2011

I’m starting to build out my first Rails application on Heroku (cedar stack), ever. Yes, I know, I’m really late to the party. But I just ran across something that might be causing folks trouble if they’re attempting to deploy a Rails 3.1 application to Heroku and prefer the sass syntax over the default scss.

(First off I want to say thanks to Benjamin Atkin for giving me the idea for this fix in this blog post about Compass and Heroku.)

As much grief as I get over it, I am still an old school Sass guy and still prefer the sass syntax instead of the default scss that is shipped with Rails 3.1. Thankfully, this is quite easy to change in the Rails configuration as show here.

# Prefer SASS, 'cause that's what real men use :)
config.sass.preferred_syntax = :sass

However, when you try to deploy this Heroku, the server fails to start. This can be discovered by running heroku logs.

`method_missing': undefined method `sass' for #<Rails::Application::Configuration:0x000000016152c8> 

As pointed out in Benjamin’s post, this is because

...Heroku only runs with the asset gems from the Gemfile when it compiles the assets, and it only compiles the assets when a new slug is loaded.
Benjamin Atkin

So I took his idea and created a Sass initializer to handle the setting of this for me, only when a Sass configuration object is available.

if Rails.configuration.respond_to?(:sass)
  Rails.configuration.sass.tap do |config|
    # Prefer SASS, 'cause that's what real men use :)
    config.preferred_syntax = :sass

UPDATE 10/02/2011

Just found out that the initializer above won’t actually get run when you run rails generate, which kind of defeats the purpose. So this code must be run from application.rb, either included directly or required.

By doing this, it allows the Heroku cedar stack to properly precompile the assets and successfully start the Rails server.

One other way to “fix” this issue is to move the sass-rails gem into the global group in your Gemfile. But I think I prefer the solution above so I don’t have to pollute the global gem group with an unnecessary gem just to satisfy Heroku deployment.

Happy coding!