public
Last active — forked from mislav/Gemfile

How to integrate Compass with Rails 3.1 asset pipeline

  • Download Gist
readme.md
Markdown

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

I prefer Bundler.require *Rails.groups(:assets => %w(development test)) with pre-compiled assets deployed to production. This is the default line from a new rails 3.1 app.

i've followed this gist tip in new rails 3.1 app. ad added 1 file app/assets/stylesheet/setup.css.scss with following code

@import "blueprint/grid"

but when i load page i see empty setup.css on it... so import doesn't work
i'm really newbie to compass and rails could you tell me what i'm doing wrong?

here is full source code
https://github.com/blackbumer/ct

You made the blueprint grid mixins available to use in setup.CSS.scss but you haven't actually used them in any styles yet.

Add a selector and call one of the grid mixins within it.

On Sep 2, 2011, at 6:50 AM, blackbumerreply@reply.github.com wrote:

i've followed this gist tip in new rails 3.1 app. ad added 1 file app/assets/stylesheet/setup.css.scss with following code

@import "blueprint/grid"

but when i load page i see empty setup.css on it... so import doesn't work
i'm really newbie to compass and rails could you tell me what i'm doing wrong?

here is full source code
https://github.com/blackbumer/ct

Reply to this email directly or view it on GitHub:
https://gist.github.com/1184843

thanks now i'm clear on it

How did you make it work? When I run 'rake assets:precompile' it precompiles all assets except my stylesheets in app/assets/stylesheets.

@FooBarWidget Did you rename your non-partial stylesheets to *.css.scss?

No. I just tried that, but it still doesn't compile them.
Application.css.scss on the other hand is compiled, but I need screen.css,
print.css and ie.css.
Op 6 sep. 2011 17:58 schreef "chriseppstein" <
reply@reply.github.com>
het volgende:

@FooBarWidget Did you rename your non-partial stylesheets to *.css.scss?

Reply to this email directly or view it on GitHub:
https://gist.github.com/1184843

Annoying. It seems you have to enumerate them:

http://edgeguides.rubyonrails.org/asset_pipeline.html#precompiling-assets

I suppose you can do a glob.

Yes, that did it, thanks!
Op 6 sep. 2011 19:06 schreef "chriseppstein" <
reply@reply.github.com>
het volgende:

Annoying. It seems you have to enumerate them:

http://edgeguides.rubyonrails.org/asset_pipeline.html#precompiling-assets

I suppose you can do a glob.

Reply to this email directly or view it on GitHub:
https://gist.github.com/1184843

Made some updates to automatically find non-partials and include them in the precompilation step.

The optional third step doesn't seem to do anything besides give an error.

Is this required for using a framework like Susy?

I attempted:
bundle exec compass install susy

but I just get:
No such framework: "susy"

Also, should the code in the application.rb be inside a file called compass.rb inside the initializer folder, or do initializers get called in the wrong stage?

Does Compass have to be required somewhere before using it?
If yes, where's the best place to do so?

@chriseppstein The precompile glob you posted doesn't work for me. It globs the files properly, but the precompile task doesn't generate anything because those 'paths' don't match the asset 'logical_paths' returned by the sprockets gem, which removes all the 'engine' extensions... so filename.css.scss.erb becomes simply filename.css... This means the globed path (w/ the '.scss') will never match the path from sprockets. The glob should work if you remove the 'engine' extensions from each globbed file. Also, based on the behavior of 'logical_path', it doesn't mater if your file is '.css.scss' or '.scss' it will return both as '.css'.

However, using the following regex, which will match anything but a partial, is a simple approach that is working well for me:
config.assets.precompile << /(^[^]|\/[^])[^\/]*$/

Susy doesn't work here either, getting same "No such framework: "susy"

Gemfile:

gem 'compass-susy-plugin', :require => 'susy'

And just running bundle exec rake assets:precompile fails with:

File to import not found or unreadable: susy.

Any updates to this for Rails 3.1.1.rc2 / sass-rails 3.1.3?

When rake assets:precompile runs, I'm getting:

File to import not found or unreadable: compass.
Load path: Sass::Rails::Importer(/app/app/assets/stylesheets/base.css.scss)

That file contains @import "compass";

Sorry, but I think there is some issure in application.rb code. Its does not generate separate stylesheets in production env.
As I understood from the Rails Guide, we must add in config.assets.precompile something like this array
['screen.css','print.css','ie.css']
not
['screen.css.scss','print.css.scss','ie.css.scss']
which generates by the script in your application.rb. My version works fine.
am I right?
PS Sorry for my english, and thanks for your awesome work.

@divinly, I have had the same experience as explained in my earlier comment. That is why I use a different regex to produce the desired results...

config.assets.precompile << /(^[^_]|\/[^_])[^\/]*$/

Update: Not sure how, but the "_" in the code above were originally removed in my copy paste... fixed now.

Is config/compass.rb still optional if you're requiring extensions? My initial guess would be no, and that if you're requiring Compass extensions to show in the "frameworks" list, you'd still need config/compass.rb to require them.

True or false?

@bensie
I got it working with this:
gem 'compass', :git => 'git://github.com/chriseppstein/compass.git', :tag => 'v0.12.alpha.0'

@adamstac if you're using the compass CLI, you need a config. But otherwise you can just require your extensions in your rails configs.

Yea I'm lpoking to still provide access to the CLI for patterns and templates.

@chriseppstein Have you tried this on Heroku with Rails 3.1.1.rc2? I'm still getting the following during the rake assets:precompile part of the deploy:

File to import not found or unreadable: compass.
Load path: Sass::Rails::Importer(/app/app/assets/stylesheets/base.css.scss)

Works fine on Rails 3.1.1.rc1.

@bensie No I have not tested that scenario. that error would imply that compass was not initialized (the railtie was not loaded).

Having the same problem as @bensie:

File to import not found or unreadable: compass/css3.
Load path: Sass::Rails::Importer(/Users/me/apps/myapp/app/assets/stylesheets/admin.css.scss)

I switched from the gem with version 0.12.alpha.0 to the Github version as @richardaday suggested, no luck.
Happens on deploy to staging and locally when I try RAILS_ENV=production RAILS_GROUPS=assets bundle exec rake assets:precompile
AFAICS started happening when I upgraded from 3.1.1.rc1 to rc2

Downgrading to 3.1.1.rc1 made the issue disappear.

@marcusmateus Thanks for you... But it seems it does not work in this kind of implementation. I have this error on it
warning: character class has ']' without escape: /(^[^]|\/[^])[^\/]*$/
So, I have some trouble with regexp and can`t understand, what going wrong.

Chris, first off thanks for all the hard work in getting compass going in rails 3.1. It works great.

Can I ask, because I can't seem to find a definitive answer online: what is the preferred method for importing? Is it @import (sass way) or /*=require (sprockets way).

It seems that sass-rails was created to allow us to use @imports (and it does indeed). But there seem to be two problems with that:
1. In development I don't get the benefit of multiple css files being linked (which is quite a boon for debugging).
2. Every time I make a change to a sass file it recompiles everything, which in my case takes around 50 seconds.

It seems possible to use a combination of the two importing methods to get the best of both words (@import for mixins, /*=require for partials) but that seems just plain strange.

Can anyone enlighten me? Or link me to the answer somewhere?

@tmeasday
AFAIK @import is much preferred over =require since the @imported mixins can then be used by other files.
As for your questions:
1. You're right. Maybe the Sass option :debug_info helps, it prints out debug info for each selector saying where it is defined (http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#options)
2. 50 seconds just to compile your Sass files? Jeez... :) I have about 60 partials by now and it takes barely a second to recompile everything... Maybe check out https://github.com/wavii/rails-dev-tweaks, works great for me.

@manuelmeurer
1. It does help, but of course you can't see it in browsers' development tools, so it's mainly useful for last ditch diagnoses.
2. Thanks for the link, not sure it would help in this case as we do need to recompile the sass, it's just unfortunate that it is taking so long.
Which does raise an interesting question:
3. Why is it taking so much longer in 3.1 to re-compile the sass than in 3.0? Was there some kind of caching going on before that is no longer enabled? (I was only using @imports before, obviously).

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

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 Colemanreply@reply.github.com 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: https://github.com/rails/sass-rails/issues/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 https://github.com/rails/sass-rails/commit/3c24e4fd8dd316079f3d52f20d85b823a022b151

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

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!

Please sign in to comment on this gist.

Something went wrong with that request. Please try again.