On larger projects it is likely that you be working with at least one other person on front-end tasks. This can be a great learning experience and be helpful to your developers too. There are several aspects that can make a collaborative project a success. I have broken them down into development tools, techniques, and review processes.
RVM As we almost exclusively use Sass on our Drupal projects, it is important to use a Ruby version manager that will allow you and the other themers to use the same version of Ruby & Ruby gems so that your compiled CSS is the same. The command line tool we use at Mediacurrent is RVM. This tool allows you to use different versions of Ruby per project. This is a great advantage, as it allows you to bounce between projects that require different versions without altering your system installed version. Win! RVM also allows you to switch between gemset environments, which is huge when working collaboratively.... however another tool that is time-saving when installing gemsets is Bundler.
Bundler You could use RVM gemsets without Bundler (“gem install gemname”), but Bundler will take on the task of gem installation and do it for you much more quickly (yay, less work!). It is simple to install on your system by using the command: gem install bundler. The gem files (gemfile and gemfile.lock), specify the required gems and dependencies for the project, and can be committed to a project repository so others can check them out, and set up their environment in the same way. Similarly if they add a gem to the gem file they can make sure that you have what you need next time you fetch the files. You may also install gems using Bundler without involving gemsets if you wanted to.
Guard Guard is a monitoring tool that can be a good friend to themers. Guard is also a gem, and should be listed in the gemfile of your project. Guard has it's own plugins, so to compile Sass it uses guard-sass. Guard-livereload is also a useful plugin that, like the name suggests reloads the page without you having to hit refresh, so your changes in your CSS file will show up magically in the browser. Note that browsers sometimes require an extension for this to work. In your project directory in Terminal, run the command guard-init to add the guard file to your project. Once the guard file is present, you can run the command guard it will start watching your files for changes (similar to compass-watch), and will also run any other extensions, such as Livereload at the same time.
Config.rb The config.rb file is also a useful place to define settings about your project. Knowing how to best utilize these can be helpful to yourself and your fellow themers. It’s likely that you are working on a development environment and then moving your project to production at some point. So it’s important to set the relative_assets value to true, which makes image paths a lot easier to write. It means you can use Compass URL helpers to simplify including images or fonts, such as: background: image-url(‘logo.png’) Enabling line_comments on in a dev environment will make figuring out where that pesky value is a lot easier.
Theming in a multi-themer environment can be tricky. Here are some common problems:
- “Bro/Ladybro, I think you were editing the same file as me in a different branch, and there was an epic merge conflict, so I overwrote all your styles.”
- “I made a mixin for that, why didn't you use my mixin?”
- “I thought we were using this unit of measure, what is this unit of measure doing there?”
- “We've been using $gray-header and $gray-footer and $gray-ultra-extreme-power-ranger-godzilla-dk-gray, why did you introduce $summerevening-gray?”
- And many others… (all of these are things that I have done to other people's beautiful work)
Most of these frustrations can be avoided or reduced by good technique.
Setting up a project
At Mediacurrent we try to standardize our Sass environment, we know what mixins we'll commonly use and will set up our custom files that way by copying them in and expanding as needed. If you are coming into a project later in the process, it is good to read and familiarize yourself with the mixin and variable files, so you can see what has been added and what the naming conventions are.
Working on a project If you are working in a version controlled environment, it is good to make changes in small batches. If possible separate your tasks into small sections and commit them often to the repository, or at least merge the main develop branch into your feature branch often. Once a task is complete, merge the branch into develop and remove it. This will reduce the merge issues that you encounter. Another way to reduce merge conflicts is to separate your theming into smaller partial sass files. By breaking down the site into smaller chunks there is a lesser chance of two people working on the same stylesheet. You can use the Gem sass-globbing to make importing these partials easier. Commenting can help other themers understand the flow of the stylesheet. This is especially useful when using mixins. Explaining how a mixin works or even providing example markup can really help out your fellow themers. Remember that if you use double forward slashes, then those comments will not appear in your compiled CSS, so comment away!
Code reviews at first may seem scary, but are really a great way to keep a theming project on target. The code review ensures that all theming standards are being kept, including sizing units, variable names and indenting. By attacking the commonly made mistakes early on, you will be able to reduce the incidence of these occurring in the future. By limiting the scope of your individual code pushes the reviews can be done frequently and changes made at the point of the commit. If you are positive about the process, it can be rewarding process that will make you a stronger themer.
Additional Helpful Links