4

I am working with really big projects which are using compass(compass sprites tools including) sass framework cli tool(compass watch, compass compile) to create app.css file. Sass of the project is using multiple @import statements to include dozens on sass partials.

Problem is that app.css file is compiling for more than 2 minutes(app.css is 70000 lines long) after each small change in any sass partial imported into app.scss file compiling all of them at once while I need only 1 line change.

I made an extensive research and found articles like this one http://blog.teamtreehouse.com/tale-front-end-sanity-beware-sass-import which is suggesting to use spockets instead of @import to include sass partials. I like the solution more than most but big refactor will be needed even to test if it will work also all global includes like mixins and variables will need to be included in each sass partial used in the project which is also not ideal.

After some more research I have found this https://github.com/petebrowne/sprockets-sass tool which should automatically transform @imports into spockets require statements for compiler and also preserve ability of global imports.

The problem is I don't know ruby and did not use anything ruby related else then "gem install" statement )))

Can someone who knows ruby help me by explaining step by step how to make compass compiler work with sprockets-sass ?

P.S Please do not suggest solutions like libsass and it's like I have tested it by excluding all compass sprite related stuff and libsass also take a bunch of time to compile 40000 lines that remained without sprites(I suspect that part of the problem is not in compilation speed but in time system needs to create 400000 line file after).

asmodianis
  • 1,056
  • 1
  • 7
  • 10
  • I have tried to use https://github.com/petebrowne/sprockets-sass in my gulp file like this but compilation speed is the same. var gulp = require("gulp"); var compass = require('gulp-compass'); path = require('path'); gulp.task('compass', function() { gulp.src('./sass/*.scss') .pipe(compass({ project: path.join(__dirname, './'), require: ["sprockets", "sprockets-sass", "sass", "compass"], css: 'cssOut', sass: 'sass', image: 'images' })) .pipe(gulp.dest('cssOut')); }); – asmodianis Oct 28 '15 at 15:14
  • Before doing this I have installed sprockets-sass like this `gem install sprockets-sass` . It seems like @import statements is still having the same nature as they had before or sprockets did not help to make compilation faster. – asmodianis Oct 28 '15 at 15:55

1 Answers1

1

The only thing that you can do is to split the output top-level file (app.css) into multiple output top-level files, and at the end of the compass-compilation reconcat them with a sprockets task!

This optimizes the usage of sass cache and the final concat-task is efficient because is a simple concatenation!

By the way, at the moment, compass is replaced with the EyeGlass Project made by Chris Eppstein the author of Compass.

So Consider the idea of a whole refactoring using (grunt/gulp) with libsass (A sass compiler built in C/C++) and EyeGlass that adds all compass-like features to sass!

hope Helps!

Hitmands
  • 13,491
  • 4
  • 34
  • 69
  • I have tried to compile all partials into separate css files, but unfortunately it is impossible without big refactor in a project , partials is using mixins from the files @imported above in app.scss so If I try to compile it separately it fails – asmodianis Oct 28 '15 at 14:01
  • you should use a shared partial across all multiple output files, for example: _application-definition.scss requires _mymixins.scsss and _myvariables.scss outputfile1 requires _application-definition.scss outputfile2 requires _application-definition.scss – Hitmands Oct 28 '15 at 14:09
  • Yes you are right of course but this way I will need to remove the _ prefix from each partial file and as I told this shared @imports will need to be moved for not 1 but multiple huge projects which is quite refactor effort which is not worth it. I doubt I will get the permission to do this refactor like this. Most likely current projects will stay as it is and future ones will be made with PostCSS. What I am looking for is less painful solution. Though I am beginning to doubt there is any) – asmodianis Oct 28 '15 at 15:26
  • :) Be careful with PostCSS, it's more performat than Libsass because PostCSS is just a Parser, when you add plugins you'll (of course) lose performances... For me, the best way to have a performant build process is: 1. EyeGlass and Libsass as a preprocessor (mixins, variables, filesystem access) 2. PostCSS used just as optimizer of EyeGlass/Libsass output, for example, adding autoprefixes and grouping media queries... :) but this is just my opinion! – Hitmands Oct 28 '15 at 15:53