Fancy front-end

Steven Grant

by Steven Grant on July 25, 2014

We've been doing a lot of front-end work lately and always looking for ways to improve how we work.

The team have recently transitioned to Gulp from a more manual, laborious process that had one person take on responsibility for deployment.

What I'll cover in this post is some of the front-end components that we're using and our deployment process with Codeship:

Is this post for you?

If you aren't comfortable with terminal, have no patience in working problems through or are a Windows user -- sorry, but you should read another one of our posts.

For those of you still with me, let's jump in.


Right off, we need the following applications/packages installed:

Next we want to allow ourselves to install npm packages without needing to sudo each time (hat tip to Aral Balkan for this)

sudo chown -R $USER /usr/local

With that done, we want to install Gulp globally on our system

npm install gulp -g

For the next part, you might want to grab a copy of our repo. It contains, a package.json with the Gulp dependencies, a gulpfile.js and some templates for font icon generation.

Next you'll want to run the next line for the node-canvas stuff to work properly

export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/X11/lib/pkgconfig

So if you downloaded our repo to your working directory, the next thing we want to do is:

npm install

This will grab the dependencies in package.json and install them to the node_modules folder.

With that done we're all set.

If you want to add your own Sass files to the mix, feel free. You'll want to do that inside src/scss

Custom web font generation

This is probably the coolest thing in Sass I've done since getting retina image sprites working for the first time.

Inside the src/media/icons directory we have a series of SVG icons, a Sass file and a fontcustom-preview.html document.

You won't need to touch the Sass file or the HTML document but we'll come back to what they do.

If you want to use your own icon SVGs, just replace the ones in there.

With that done, you jump back to terminal and run

gulp icons

What this in turn does is examine the fontcustom.yml file at the root of the project sets the Sass file and the HTML preview document as templates.

It then loops through those 2 templates to place an _icons.scss inside your src/scss dir and an icons-preview.html inside public_html/build/fonts as well as generate your custom web font from your SVGs.

All being well, your dir should something like below

custom fonts FTW

I was all

when this worked.

You can now add that _icons.scss partial to your main Sass file. You can then use the output as you wish. The _icons.scss partial has an appropriately named class for your individual icon, the character code, a Sass variable and a mixin.

I tend to use the mixin personally but these options give you enough flexibility.

I initially wanted to use Sass maps but there's an issue with Gulp Sass support.

CSS sprites

The only reason we'd been using Compass in our Sass was for the Retinator & Susy. On our recent Paul McCartney project, this was the piece of the build that took time each time it changed.

Our new version allows us to do away with that. We can drop our sprite images (PNG format) into src/media/sprite. If you want retina images then you just need to source the PNG at 2x the normal size. You don't need to have, for example, normal.png and [email protected] Back on the command line we can then run

gulp sprites

and it will create sprite.png and sprite-x2.png inside public_html/build/img and a _sprite.scss inside src/scss

Then to use with our markup, we call it like so

<div class"sprite original-image-name"> 

and we'll get a nice, retina ready, background image sprite.

Almost there...Codeship deployment

One of my biggest frustrations with Sass was finding a way to deploy the compile without tracking CSS files within Git. If you did and you're working in a team environment, you'd generally find conflicts between each merge and it just becomes a headache.

So we wanted a way where we committed *.scss files and these would then compile and deploy to the appropriate environment.

I started off looking at the usual build server suspects like Bamboo, TeamCity and Jenkins. All are pretty advanced solutions, overkill for what we wanted to do.

I then came across Codeship. Now Codeship as well has some advanced build server mechanics but when you're working with ExpressionEngine, Craft etc. you're not testing their code, we just want to test our Sass compiles OK.

So the first thing to do with Codeship is create your project and then link it to your Git repo (we use Bitbucket). With that done you can then configure your tests. Here's ours

codeship tests

What this is doing is saying we want a Node.js stack, we're testing against Gulp so we need that installed, we then need all of our project dependencies from package.json (just like we did locally) and then to test, we run the gulp sass task.

Then each time someone pushes to the repository, Codeship runs the test and spits out a notification of success/failure via email and also to our #build channel within Slack (notification overload really).

If you look at Codeship post build, you'll see one of these

success or failure 

Now, depending on the success or failure defines what happens next.

For us, if the build passes we then use rsync to deploy from our build. The great thing about rsync is that it will only replace what needs to be replaced since the last upload.


Right now, our build fails :) This is because of the dependencies that we installed first-off. We need to alter our package.json a little bit to only install dependencies and not dev dependencies.

Here's a little more about what you'd need to do there.

In addition to that, Codeship attempts a build on every. single. push :( 

It's my only criticism at this point and their service has been top notch thus far.

If you have questions, suggestions let us know and feel free to fork the Git repo and make changes.


comments powered by Disqus
next postprev post