http://stackoverflow.com/questions/86018/what-is-the-best-method-for-sto...
I found this question on StackOverflow about SASS in a RoR project. I am facing the same issue in my Drupal Project.

Many people dislike storing generated code or compiled code in version control, and it also stands to reason that the public/ directory shouldn't contain elements that you don't send to the browser.

Right now I'm using the Zen Starterkit theme, and I'm checking in all SASS files and all generated CSS/PNG's directly into the theme folder.
I've chosen to compile the CSS to a compressed format and I've added a PLEASE_DO_NOT_DIRECTLY_EDIT_CSS_FILES.txt and an INSTRUCTIONS_COMPASS_SASS.txt in the /css folder.

This approach still raised a couple issues:

  • Contributors to the project are forced to install and run SASS (+Ruby) while editing css
  • Some have raised concern for CSS merge conflicts. (conflicts which, imho, could be easily fixed by merging your SASS file and recompiling the result)

So, what is the best pattern to follow when laying out SASS resources in your Rails Drupal project?

Comments

JohnAlbin’s picture

Many people dislike storing generated code or compiled code in version control

That’s dogma over practicality.

I should point out that exported Views code and exported Features are ALSO generated code.

And it’s extremely practical to deploy updated code using Git and simply pushing a new commit (or tag) to the production server. Why add the extra burden of “Oh, now I have to go to the production server and re-generate my CSS.”?

I should point out that the StackOverflow article you link to is about Ruby on Rails which has an entirely different deployment strategy, so it doesn't really apply to PHP apps.

Contributors to the project are forced to install and run SASS (+Ruby) while editing css

If you are editing CSS at the theme-level, you should be using the same toolset as everyone else. i.e. Use Sass. This is a ridiculous argument, IMO. Like saying module developers are "forced to use jQuery" when using Drupal’s javascript. And, no, you don't need to install Ruby, Sass, and Compass; there are plenty of GUI apps that have that toolchain embedded in them and don't require their separate installation.

</rant> I'm not ranting at you, tdskate, just at the people who raise the argument. :-)

Some have raised concern for CSS merge conflicts. (conflicts which, imho, could be easily fixed by merging your SASS file and recompiling the result)

I completely agree with your statement that this can “be easily fixed by merging your SASS file and recompiling the result”. To make merge conflicts even less of an issue, I recommend adding the generated CSS in a separate Git commit. Which means if you screw up the merge conflict entirely, you've only fouled up the commit that contains a generated file anyway. Regenerate, re-commit, done.

  - John (JohnAlbin)

Snugug’s picture

I essentially agree with John on all of his points, with the following exception:

If you have full control over your server, I actually like to build Sass compiling via Compass into the git deploy script precisely because it alleviates the possibility of not having the most up-to-date CSS on server with your Sass and because it will get rid of the merge conflict issue. It also saves me an, IMO, pointless and prepetitive commit (I commit my CSS separately than my Sass and at the end to reduce CSS conflicts potentially messing up a merge when they truly are worthless conflicts). This also allows me to develop locally using expanded output with Sass debug info on, and actually use on my site a fully minimized CSS file thanks to development/production mode in Compass.

That all said, if you don't have control over your server or don't want to build out deployment stuff (like if your hosted on Acquia or Pantheon, for instance) I commit CSS straig into version control too, also minimized.

moshe weitzman’s picture

Acquia Cloud Hooks let you run arbitrary scripts during a deployment. Perhapsyou could avoid putting generated css into git even with Acquia. If anyone tries this and you find it lacking, please Contact me.

mdeltito’s picture

Agree with all of this.

And, no, you don't need to install Ruby, Sass, and Compass; there are plenty of GUI apps that have that toolchain embedded in them and don't require their separate installation.

Even assuming there are times when the GUI apps fall short (say, if your project uses a gem or other lib not supported by the app), dependency management for Ruby gems is a problem that is already solved. With Bundler you can easily specify your project's dependencies, and other developers can simply run bundle install after cloning to ensure their environment contains the required gems.

Yes, this assumes all contributors have Ruby installed. At this point though, it really isn't terribly difficult to get up and running with Ruby on any platform.

- Mike

Spanners’s picture

I'm with John on this. Particularly when the git pull command is used to deploy changes to a live server.

Simon Olsen
--
Follow me on Twitter - http://twitter.com/spanners80
Connect with me on LinkedIn: https://au.linkedin.com/pub/simon-olsen/12/359/143

Fabianx’s picture

The easy answer:

Use branches:

* Dev: Don't have CSS commited, no conflicts, etc.
* Production: Have CSS commited for production usage. Here Updates and History are actually helpful.

Merge Dev -> Update CSS -> Push Prod -> Done

Problem solved (tm).