Needed badly - an RVM / bundler config that will just work (with sourcemaps).
I've spent probably an entire week over the last month trying to get and keep omega compiling. i'm not that fussy, just want to be able to run susy (any version) with breakpoints (via susy or breakpoint) and compass - with sourcemaps for debugging.
I have had RVM and bundler managing things for months now. I've hired several ruby people to help, I've dallianced, buying codekit 2.0 (if only that would work, libsass 'n all - that would be so sweet).
But i just can't make this work - Generally I end up in a circle of dependencies that just goes round and round. With help, we something that worked, but only with 1min compile time. By gutting imports we got that down to 20sec. And then somehow I broke it anyway.
Could you advise or supply a gemfile that will meet these criterion
Ideally capable of susy 2 supporting susy 1 via @import"susyone"; - but really -just anything that will work, with sourcemaps.
I have burnt up a week of unbillable hours on this - would be glad or some help, also happy to pay for it.
thanks
PS here's what kind of worked…
gem 'sass' # Sass.
gem 'sass-globbing' # Imports via globbing pattern.
gem 'compass', '= 1.0.0.alpha.19' # Framework built on Sass.
gem 'compass-validator' # So you can `compass validate`.
gem 'compass-normalize' # Compass version of normalize.css.
gem 'compass-rgbapng' # rgba() > .png's for compatibility.
gem 'susy', ">=2.0" # Susy grid framework.
# gem 'singularitygs' # Alternative to Susy.
gem 'toolkit', '~>2.0' # Compass utility by Snugug.
gem 'oily_png' # Faster Compass sprite generation.
gem 'css_parser' # Helps `compass stats`.
PS2: a lot of the dependency incompatibility appears to have hung around the need to use new-ish versions of sass and compass to support sourcemaps, but omegas continuing dependency on older version of toolkit.
Comments
Comment #1
timoti CreditAttribution: timoti commentedComment #2
dw72 CreditAttribution: dw72 commentedI tried setup this too, but with no luck :( Somebody knows a way to use susy2 with omega4?
Comment #3
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedAfter long hesitating between Foundation 5, Bootstrap 3, Susy 2, Singularity, Zen Grids and Bourbon Neat grid systems, I finally decided to go for Susy 2 last night and I come here today to share my sadness that it does not work with Omega 4 yet :(
Comment #4
fubhy CreditAttribution: fubhy commentedThere is nothing in Omega 4 that prevents any Gem stack from functioning. If a Gem works somewhere else, it also works in Omega 4. All you have to do is properly adjust your Gemfile. The one that comes with Omega 4 (and the starterkit) is just pre-defined configuration. You can change that anytime. I'd guess that there is a Susy 2 installation tutorial on the susy website (susy.oddbird.net). Make sure that you follow the instructions and use the Gem versions advertised there. It may also be required to bump your Ruby version if you are not yet on > 2.0. I personally don't use Susy because I am a big Singularity fan but it should be easily possible to install Susy 2 by simply adjusting your Gemfile accordingly and possibly bumping your Ruby version. Start simple (just put Susy in there for the start), then continue from there and add whatever else you need for your stack (compass, globbing, toolkit, etc.).
Comment #5
fubhy CreditAttribution: fubhy commentedI am however probably going to bump our Gemfile in the near future anyways. I am not sure yet what I will be doing with Susy yet as I actually didn't have any plans of keeping that there. I might actually create a second gemfile just for Susy though. However, the default for the starterkit will be Singularity.
Comment #6
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedBecause Susy 2 is brand new and states that they joined forces with Salsa and borrowed from Zen Grids and Singularity, I naively assumed Susy 2 was the best option right now. Are there any particular reasons why you would still recommend Singularity over Susy 2? Or an article I could read that would make me see things your way? I actually would be glad to have reasons to use Singularity since it already is working with Omega... I just don't want to go with Singularity and find out in three month Susy 2 would have been the better choice... But maybe they are just so similar that it does not really make any difference?
EDIT: I guess this thread would be better for you to answer me...
https://drupal.org/node/2064087
Comment #7
dw72 CreditAttribution: dw72 commented@fubhy I know this is not problem with omega4, but the dependency hell between gems... maybe someone resolve it now and have a good receipe (gem versions) to use susy2 with other gems from omega Gemfile?
I ended with:
with Gemfile (rest of entries without changes):
Comment #8
Marko B CreditAttribution: Marko B commentedAny data on source maps. How to use sourcemaps with any version of omega 4?
Comment #9
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedHi there, I managed to use Sass 3.3 + Susy 2 or Singularity 1.2 + Compass 1.0 + Breakpoint 2.4 + Sass Globbing + Autoprefixer + Normalize.scss v3 with Omega 4.
If you want to use Guard, you can, but guard-compass 2 is not compatible with compass 1.0 (because of listen dependency) so Bundler will use latest 1.x version of guard which is old. I've tried, it works, except for LiveReload which version was too old to work on latest browsers.
Compass 1.0 is required if you need Sass 3.3. Which means compass 1.0 is required if you need sourcemaps for debugging or/and Susy 2.
Sass 3.3 and Compass 1.0 are also required by the latest version of Normalize.scss by John Albin https://github.com/JohnAlbin/normalize-scss which is what I use personally and is "the official Normalize port for Drupal" https://drupal.org/project/normalize if I believe the Zen project page.
So if you want to be able to use LiveReload + Sourcemaps + Susy + latest Normalize.scss, and maybe also don't have any other problems due to guard 1.x, I suggest you use Grunt instead. Which is very popular.
Now, requiring Compass 1.0 as a dependency does not mean that you need to compile with compass and the config.rb file. You can do that, using grunt-contrib-compass. But you can also use Sass directly to compile the sass using grunt-contrib-sass and which can require compass for dependencies.
Autoprefixer works in config.rb with autoprefixer-rails but it can also be configured as a grunt task with grunt-autoprefixer. Which I prefer because I can then exclude the autoprefixer task from my watch task. I only run autoprefixer for my final 'build' task. Same thing for normalize.scss and no-query.scss which I don't need to regenerate while developping, which compass does everytime. Or maybe I could have used a more granular config than just the global "sass_dir"...
If you don't need:
- Susy 2 (because you prefer Singularity or don't actually need any Grid Toolkit for you layouts)
- sourcemaps (because your sass is already very well organized thanks to globbing)
- and you don't care about having the latest version of normalize.scss
- and Sass 3.2 and Compass 0.12 are ok
then you can also use grunt-sass (Libsass) which is 100 times faster to compile your sass.
So here is the interesting part of my Gemfile:
here is my package.json file :
and here is my Gruntfile:
Basically the Gruntfile is composed of the following tasks:
- watch
- shell
- sass
- compass
- autoprefixer
- jshint
- uglify
if you run
grunt sass
it will execute sub-taskssass:dist
thensass:dev
thensass:styles
so this is useless. You need to indicate which sub-task to run.I use the
grunt sass:dev
command to compile all scss files in the sass folderI use the
grunt watch
command while developping which only regenerates the omega_subtheme_name.styles.scss (triggering sass:styles task)In the end I can use grunt build to compile everything (sass:dist) with autoprefixing.
Note that I haven't removed all the grunt-contrib-compass part but I don't use it anymore
To use grunt-contrib-compass, uncomment the compass tasks in the 'watch' and 'build' tasks and comment the 'sass' tasks instead.
You can run grunt compass:dev and grunt compass:dist also independently.
If you prefer to have your compass config in config.rb, uncomment the line //config: 'config.rb', //not needed anymore. You can then remove all the redondant options.
Comment #10
fubhy CreditAttribution: fubhy commentedGood post Nicolas! I have a similar config in my Silex boilerplate on GH using Gulp: https://github.com/fubhy/silex-boilerplate
Comment #11
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedThanks! I haven't had a look at Gulp yet. Do you think I should or it isn't particularly better than Grunt, just different? A bit like Singularity vs Susy 2...
Comment #12
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedAlso, how much do you actually use Singularity for your layouts? So far I have the feeling I'm having a harder time to find out how I should write things in Susy 2 or Singularity compared to if I was just applying width and margins myself...
Comment #13
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedAlso do you actually use sourcemaps? Because now that I use globbing thanks to omega I know right away where to look at...
Comment #14
Marko B CreditAttribution: Marko B commentedI was running a working Omega 4 this morning, wanted to put Sass 3.3 version from 3.2 to see how sourcemaps works but now I got a mess :)
When I run guard I get
I really can't debug where the problem now occurs and why I get this message. Also I don't understand when you talk about Compass v 1.0 as compass seems to be in 0.x version and I have it gems/ruby-2.1.1/gems/compass-0.12.2
Comment #15
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedI can't help you with your Guardfile problem but I really encourage you to use Grunt instead.
Compass 1.0 is the pre release of Compass (not stable release).
I literally spent 2-3 days reading a lot and testing a lot to understand all there is behind all that. I believe from the type of questions you ask that you should spend some time too trying to understand a bit more what's going here and what all the players are... it'll save you time later on.
Comment #16
fubhy CreditAttribution: fubhy commentedGulp and Grunt are both nice, however I find Gulp is much more controlable and nicer to work with due to the syntax. You basically *code* your workflow instead of configuring it which results in a nice and readable set of chained function calls instead of massive json configuration.
I would also say that exactly due to that, it's easier to get started with.
Comment #17
Marko B CreditAttribution: Marko B commentedThe problem with all this omega/sass workflow is some kind of promise or feeling you "won't" need to learn ruby and all that comes with it, but you really need to Learn Ruby and you need to know it well. If not you are left with just plain luck and writing commands and installing stuff hoping it works. Would recommend that in documentation we just put, learn basics of ruby setup and how it works. Then people will hate all of this less and will be less issues how to install omega 4 and its workflow (think there is a lot of it right now).
Comment #18
Marko B CreditAttribution: Marko B commentedWhat I realized is that If i put in gemfile.lock file sass (3.3.8) I get error below. If i revert it to sass (3.2.10) workflow is back and everything works.
Have 2 questions.
First any ideas why I get this below when on 3.3.8 version, dont understand what is this output telling me?
Second, all this time I was trying to activate sourcemaps, and most tutorials online say "sass style.scss style.css --sourcemap" to run that. But in omega 4 we dont run it anywhere we use guard :compass do watch(%r{.+\.s[ac]ss$}) end so I m wondering where would I put this sourcemap option anyway?
Comment #19
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedI don't have the feeling that I have had to learn ruby... I just needed to understand how the Gemfile of Bundler works... or at least how to specify versions... but that's only because I wanted the best (sourcemaps, susy, etc.). Omega 4 works out of the box if you don't need all the latest toys...
When you make coherent modifications to your Gemfile you can safely / must delete the Gemfile.lock before running
bundle install
.The source maps are automatically handled by grunt-contrib-sass and grunt-contrib-compass via the
sourcemap: true
option that you can see in the Gruntfile.Now for the browser to actually see those generated .map files, there must be a comment at the end of the .css file /*# sourceMappingURL=omega-custom.styles.css.map */
In my case this wasn't automatically added by grunt-contrib-compass (did not think it was a bug at that time) but it is automatically added by grunt-contrib-sass
Comment #20
VISIOS CreditAttribution: VISIOS commented@Marko B
#18
You have to install the latest compass version to make sass 3.3.8 work with compass.
gem install compass --pre
This will install compass 1.0.0.alpha.19. Spend a view hours today resolving this. The only drawback is, that livereload won't work anymore because there is a dependency between compass alpha and listen which makes it impossible to install guard an guard-livereload >= 2.0. See this issue: https://github.com/chriseppstein/compass/issues/1634
Comment #21
Marko B CreditAttribution: Marko B commentedI am doing that. But can't get it to push to 1.0 version, I even used RVM gemsets and created a gemset installed compass 1.0 alpha as instructed here http://rvm.io/gemsets/basics and then when I check compass -v I keep getting 0.12.6 version ahhh I'll just give up for now and use the 3.2 sass and that is it.
Comment #22
bradjones1For what it's worth, the gems recommended on this StackOverflow post are compiling my SASS with Sourcemaps, with an otherwise pretty vanilla install of Omega 4. Not saying it's a "fix" but it did help get me where I needed to be in the short term.
http://stackoverflow.com/questions/16877028/why-does-compass-watch-say-i...
Comment #23
Ninowis CreditAttribution: Ninowis commented@Marko B
I had the same problem, I think its due to the Gemfile.lock (which save your latest working configuration)
If you edit the Gemfile (not the lock) as per Nicolas guidelines (specifying versions to use) and then run bundle install (which might make you do some further updates), you should get away with it.
@Nicolas
Thanks a lot for sharing, I struggled for days trying to get all my new toys up to date
@who it may helps
I kept having further compiling issues even after updating all these gems, some of them then needed to be added to the 'require' list in the config.rb file (breakpoint, singularitygs, toolkit) and some @import toolkit(/no-css and /border-box) needed to be replaced by simply '@import toolkit'
Comment #24
jwilson3I wrote up a post of my adventures adding Sourcemaps to Omega 4.x
http://jwilson3.postach.io/add-source-maps-to-omega-4-x-projects
Should this rather be a feature request instead of a support request? If so, I have a patch I can contribute.
I believe all the stuff about grunt and gulp above is not necessary to support sourcemaps, and is a separate (but very worth!) discussion.
The first step is just to get Omega updated to use sourcemaps with the least amount of code changes possible. I have a patch that does that.
I'm thinking this thread has turned out to be a kind of "meta" discussion, so i should post the patch on #2311593: Chrome and SASS source maps, where there is a clean slate and things are more to the point.
Comment #25
Marko B CreditAttribution: Marko B commentedjwilson3, great for this post of yours, also as you mentioned "meta discussion" I am wondering with new D8 and twig and all the new developments in world of css/js will omega be made for D8?
Comment #26
jwilson3Reading through https://www.drupal.org/node/2258987 and looking at the zip file, seems like sass and twig is already there. But there is still work to be done on the layout systems (all files in styles/scss/layouts/ are empty), and config.rb (and more over the compass dependency) has been removed. So there is definitely more work to be done to make the 8.x theme a smooth ride into the "modern" front-end stack -- with css pre-and-post processors and task runners running amuck.
Comment #27
fubhy CreditAttribution: fubhy commentedI added a very lightweigt LibSass based starterkit to Omega today and named it "Default". The Ruby based Starterkit previously named Default is now called "Dusty".
Was about time.