How to integrate Compass with Rails 3.1 asset pipeline

readme.md

This gist is no longer valid. Please see Compass-Rails for instructions on how to install.

I'd say if it takes 50 seconds to recompile your Sass files, that is definitely an issue worth investigating.
I wouldn't know how to go about it, though... :)

Hmmm.. so compiling sass from the command line is taking around 3s. Even if I am sure to delete the .sass-cache. So something is definitely wrong. I guess I will have to look around as to why that is happening, unless anyone here has any ideas?

Having said that, can anyone else confirm that @import is the way I should be doing it? Cheers.

Looks like assets:precompile issue is resolved in rc3 :)

@arronchi: confirmed, works fine here too. no more "can't find susy/compass".

Same here -- rc3 fixes the Heroku issue.

btw, how font-files helper doesn't work for 3.1 assets pipeline
i tried use
@include font-face("PictosRegular", font-files("pictos-webfont.woff", woff,"pictos-webfont.ttf", truetype));
but result was
src: url(/assets/pictos-webfont.woff) format('woff'), url(/assets/pictos-webfont.ttf) format('truetype');

urls without quotes...
fonts doesn't load on page..
how to fix it? (if i type localhost:3000/assets/pictos-webfont.ttf i can download them...)

Not working for me using Rails 3.1.1, I get this error:

j2(master): rake assets:precompile             
rake aborted!
undefined method `directory?' for nil:NilClass

Tasks: TOP => assets:precompile:primary

I would post the stack but nothing in it is from my app, all from gems.

@bensie after upgrading to rc3, I encounter the same message than @manuelmeurer
File to import not found or unreadable: compass/css3.
It is solved once I roll back to rc1. If I use 3.1, I get the heroku compilation error about *.png file not being precompiled...

Anyway, also, I found an issue during my debug process. When under rc3 on my localhost, when I was using

`````` asset_url('path/to/my_file.png',images)in my css to get the reference to an image, it was trying to access the path .../images/my_file.png```
instead of
```.../assets/my_file.png```
I had tried using image-url just like the RoR documentation suggests to do but it seems that this doesn't work anymore. So in the end I tried and got success with the following:
```asset_url('path/to/my_file.png',assets)```
which is pretty ugly...

For info, now I have:

group :assets do
  gem 'sass-rails', "~> 3.1.4"
  gem 'coffee-rails', "~> 3.1.0"
  gem 'uglifier'
  gem 'compass', :tag => "v0.12.alpha.0"
end

```
Sorry if I am not clear, I tried a lot of things on Friday and didn't have time to post it right away... I can re-run some tests and get you more details if interested...
```

This worked for me (upgrading from Rails 3.0.10 to 3.1.0), thanks for posting this!

@tmeasday any luck on fixing the slow sass compile times within Rails 3.1's asset pipeline? I'm seeing the exact same thing.

@whather: We never got to the root of the problem, but we managed to refactor our SCSS in some ways to make it bearable. Would you like me to send you some details about what we did? Off the top of my head it's mainly in a) never using @extend. b) Not using large @Mixins too much. It was a bit of a drag and forced us to refactor in ways that we didn't really want to do, but the situation is better now. Let me know if you are interested in some more details.

@tmeasday I would love to know more about what you did. We never use @extend but we do have a lot of mixins (=sample-mixin). I am finding that @imports are super slow and I'm contemplating switching back to jammit, where sass complication was much faster.

@whather: Yes, chatting with my coworker and looking through the commits, I think the biggest thing was large mixins.

We have some large mixins that control many aspects of page layout, called e.g. layout_behind. Previously, we had code that looked much like (for example):

.c_profiles.v_show { @include layout_behind; }
.c_profiles.v_edit { @include layout_behind; }

This would be repeated many times, basically once for each view of the site. To fix it up, we pulled them all together into a single line:

.c_profiles.v_show, .c_profiles.v_edit { @include layout_behind; }

Although I can understand that the second will produce less CSS, and is probably a better approach to run with for performance reasons, the first made a lot more sense for our code organisation, so it was a drag that we had to change. I won't pretend to understand the internals of SASS and how the compilation works, but the compile times we were getting were obscene.

Anyway, probably a similar workaround is possible. Worst-case scenario, I can imagine scattering some classnames around might help avoid repeating mixins (which would suck, I'm sure). Let me know if I can help further.

Tom, Did the number of import statements also decrease as part of that refactor? I'm 99% certain the issue is related to imports - not including mixins. That said, large files being slow was an issue until recently if compression was enabled. Does any of this ring a bell? Hunt & pecked on my iPhone... Sorry if it's brief!

…

On Nov 28, 2011, at 5:03 PM, Tom ***@***.*** wrote: @whather: Yes, chatting with my coworker and looking through the commits, I think the biggest thing was large mixins. We have some large mixins that control many aspects of page layout, called e.g. `layout_behind`. Previously, we had code that looked much like (for example): .c_profiles.v_show { @include layout_behind; } .c_profiles.v_edit { @include layout_behind; } This would be repeated many times, basically once for each view of the site. To fix it up, we pulled them all together into a single line: .c_profiles.v_show, .c_profiles.v_edit { @include layout_behind; } Although I can understand that the second will produce less CSS, and is probably a better approach to run with for performance reasons, the first made a lot more sense for our code organisation, so it was a drag that we had to change. I won't pretend to understand the internals of SASS and how the compilation works, but the compile times we were getting were obscene. Anyway, probably a similar workaround is possible. Worst-case scenario, I can imagine scattering some classnames around might help avoid repeating mixins (which would suck, I'm sure). Let me know if I can help further. --- Reply to this email directly or view it on GitHub: https://gist.github.com/1184843

Chris,

No, the number of import statements was and is relatively large (of the order of 1 file per view in the project). Possibly this is the reason why sass is slow for us, esp. in rails vs command line (for more details you can see this bug: rails/sass-rails#67).

I guess we haven't really resolved our slowness, just managed to bring the compile times down far enough that it's no longer a pain point. But changing the use of @includes made a huge difference.

PS. When you say until recently, are you referring to sass-rails 3.1.5? It doesn't seem to make significant difference.
PPS. Re compression: I'm not sure. Is this enabled by default in dev?

Yes, 3.1.5. And compression should be off in dev mode so that's probably not going to make a difference. Just to be sure: you're using @import and never the sprockets require comment, right?

Yeah, that's right. We experimented with using require, but that had its own problems.

I'm having an issue getting compass and blueprint to work with my project, even though I have followed all the steps... (all of this is in develop) Rails 3.1 Ruby 1.9.2

I originally installed compass, and then called compass init rails --using blueprint. It claimed it worked fine. I then went and relocated the stylesheets into the correct directory.

I have the standard partial called _base.scss inside its own partial folder and four stylesheets called
application.css.scss
ie.css.scss
print.css.scss
screen.css.scss
all are in the app/assests/stylesheets

I call each of them by using the stylesheet_link_tag '*.css'....
When running the rails server, it fails
Cannot find or import: blueprint/reset
So I go in and remove that clause, again,
Cannot find or import: compass/reset
...again
Cannot find or import: blueprint

and it goes on forever with me removing each line until nothing of
compass or blueprint is being called...

If I stop calling any stylesheet except application.css.scss, which is written in basic css with no compass or blueprint calls, the site runs fine. The second I add @import "blueprint";
the site crashes again saying cannot find or import blueprint.

Its as if compass and blueprint aren't really inserted into my project as it claims.

What am I missing?

I assume it's just a typo, but app/assests should be app/assets.

Yup, that's a typo... Though I wish it was something that stupid! haha

Found my issue. I had 0.11.5 installed!

I'll note here that trying this out with Rails 3.2.0.rc1 appeared as if compass wasn't loaded when I tried to include it at the top of my application.css.sass on a fresh Rails project. Downgrading everything back to rails ~> 3.1 worked for me. Just a heads up.

Edit: d'oh! Issue has already been opened.

Temporary fix for 3.2.0.rc1: make sure sprockets is declared above sass-rails in your Gemfile:

gem 'sprockets'
gem 'sass-rails'
gem 'compass', '0.12.alpha.2'

Asset pipeline fun continues...

Thanks, @bensie, that seemed to do the trick. What does that accomplish, do you know? I'm not extremely familiar with bundler, but does that make a certain version of sprockets a priority over what compass normally uses?

Sprockets was removed from the sass-rails Gemfile in rails/sass-rails@3c24e4f

While the reasoning behind it makes sense, there's clearly more work to be done to get the load order right.

This was fixed in rails/sass-rails@f8faec5

Not sure is anyone is running an issue upgrading from Rails 3.0 to 3.1.3 with Compass v0.12.alpha.4

File to import not found or unreadable: compass/reset.
Load path: Sass::Rails::Importer

Add this to your application.rb:

 config.sass.load_paths << "#{Gem.loaded_specs['compass'].full_gem_path}/frameworks/compass/stylesheets"

Will fix this issue.

FWIW, with rails 3.2.0, there is no need to add sprockets to your Gemfile, and the following assets group works fine:

group :assets do
  gem 'sass-rails', '~> 3.2'
  gem 'coffee-rails', '~> 3.2'
  gem 'uglifier', '~> 1.0'
  gem 'compass', '~> 0.12.alpha'
end

This gist is no longer valid. Compass v0.12 release candidate is out and should make rails integration a snap. Please see https://github.com/compass/compass-rails for details.

@chriseppstein thanks for all your work on this!