This gist is no longer valid. Please see Compass-Rails for instructions on how to install.
-
-
Save chriseppstein/1184843 to your computer and use it in GitHub Desktop.
How to integrate Compass with Rails 3.1 asset pipeline
@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.
@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!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@tmeasday any luck on fixing the slow sass compile times within Rails 3.1's asset pipeline? I'm seeing the exact same thing.