2014 in review: the year a build step appeared

Until this year my CSS workflow was: open the file, type CSS, save, refresh. On 10 October I committed a Gulpfile.js for the first time, under a commit message that just says "Something special." The same month the first .less files landed, and back in August I had written a test suite I actually ran.

Three habits, one year. Here is what each of them was worth.

Less, and why the mixins mattered more than the variables

Everyone sells preprocessors on variables. Variables are nice. Mixins are what saved the hours, because in 2014 a rounded corner with gradients still means five prefixed declarations, and typing those by hand is how you end up with three buttons that are almost the same.

The boilerplate I use for a new project:

/* Default functions */
@import "mixins";

/* Use your preferred reset stylesheet, e.g. http://git.io/normalize */
@import (inline) "reset.css";

/* All the basic styles, mobile first */
@import "basic";

/* Tablets */
@media screen and (min-width: 768px) {
    @import "res_768";
}

/* Desktop */
@media screen and (min-width: 978px) {
    @import "res_978";
}

/* Large desktop */
@media screen and (min-width: 1200px) {
    @import "res_1200";
}

One entry file compiles to one minified all.css, responsive rules included. In every imported partial you repeat @import "mixins"; on line one so the compiler can find them.

Keep the partials structured the way the page is structured:

header { }

.mainContainer {
    section {
        position: relative;

        .entry-content {
            p {
                margin: 0 0 1em 0;

                &:last-child {
                    margin-bottom: 0;
                }
            }
        }
    }

    aside { }
}

footer { }

On Windows I use a small GUI that watches the folder and compiles on save. No terminal, no config file, and my CSS is production-ready the moment I hit save.

Gulp

Compile, prefix, minify, concatenate. Nothing here is new work, it is work I was doing by hand and forgetting to do before a deploy. Automating it did not make the sites faster. It made them consistently as fast as I had claimed they were.

The first dependency list says what I set it up to do, and it is more revealing than the gulpfile:

"gulp": "^3.8.8",
"gulp-less": "^1.3.6",
"gulp-sass": "^1.1.0",
"gulp-autoprefixer": "^1.0.1",
"gulp-concat": "^2.4.1",
"gulp-uglify": "^1.0.1",
"gulp-minify-css": "^0.3.10",
"gulp-rev": "^1.1.0",
"gulp-notify": "^1.8.0",
"gulp-phpunit": "^0.6.3",
"gulp-phpspec": "^0.3.0"

Two things in there date me precisely. I installed both gulp-less and gulp-sass on day one, and then spent the next five years half in one and half in the other before finally committing to Sass. And gulp-phpunit sits next to the asset tasks, because the same runner was firing my PHP tests. One command to build the front end and prove the back end still worked.

gulp-rev is the one I would defend hardest. It rewrites filenames with a content hash, so a stylesheet can be cached forever and still update the moment it changes. Before that, every deploy came with "please press Ctrl+F5".

Writing my first real tests

Added a test suite to the framework project in August. Not many tests, and not the interesting kind. Mostly: does this calculation still return what it returned last month. That is the one that catches the bug the client would otherwise find in an invoice.

In short

Added a build step, Less, and a test suite I actually ran.

The year in commits