Earlier this week, we released a new version of our Kunstmaan Bundles CMS. Together with a bunch of improvements for website administrators and developers (more information here and here in case you missed it) our front-end workflow and demo-site also received a complete overhaul. This blogpost aims to serve as a guide through the major changes.

Never change a winning team? Migrating to gulp.js

When gulpjs came out, we were curious to see what the differences were between gulp and grunt in regard to workflow automation. Having been using grunt as our major task runner for little over two years we decided to give gulp a go as well. After some tests the advantages were clear: gulp is faster, focusses less on configuration and keeps things much simpler in general, resulting in cleaner, more manageable and comprehensible code. So to make things short: we decided to migrate to gulp, boxed with the new version of our bundles you’ll get our shiny new gulp file to manage your project.

A heart splitting break-up between tasks and config

De-polarisation of tasks and config: both are given a separate file which makes things easier to maintain and much more transparent and reusable. All tasks are defined in the basic gulpfile.js, project specific configuration is located in the .groundcontrolrc file so you basically never have to touch the gulpfile, unless you need some very specific tasks, all you need to adjust is the project specific config (paths, browser support, live reload files, …) in the groundcontrolrc file.

An example of a .groundcontrolrc file.

Error handling

We built an error logger right into our gulp file, this gives you all the information you need for debugging right into your command line interface. We made sure that these error messages stand out from the crowd so they’re easily noticeable in for example the default gulp watch task. 

error messaging

Main tasks included:


Styles are compiled and minified with the gulp-ruby-sass plugin, this default task combines all your media queries with gulp-combine-mq and autoprefixes your code where needed, which uses the browser support defined in the .groundcontrolrc file.


For our javascript files we made a differentiation between the production and development environments. We used to combine, uglify and minify all our files into one main file, which in turn is included in the project. Which made debugging in the development phase a pain sometimes. To remedy this we made a differentiation between the development and the production built of a project. Both are managed by a different task, the development js task doesn’t minify or combine your javascript files, it just inserts them into your project. So when you have to debug a piece of code you, can actually read the files. When the project is ready to be built on a production server the production js task handles the minification and uglification of your javascript files and combines them into one production ready .js file which in turn will be injected into the project.


Images are optimised using gulp-imagemin.

Default watch

Gulp watch is your main development task, it starts up a live reload which listens to changes of the files defined in the .groundcontrolrc file. It also runs the development version of the javascript task and the main style and image tasks and builds the style guide which will be discussed later in this blog.

Default build

The build task starts with cleaning all your caches, handles styles and images and features the production version of the javascript task, it also builds our style guide.

gulp build run

Bundler & styleguide


All things evolve, especially so in the world of web. So what happens if you have to work on a slightly or much older project? Your installed ruby gems tend to be at a much more recent version then when you first developed the project back in the day. Which meant downgrading to the appropriate version. Enter Bundler

From the bundler website:

“Bundler provides a consistent environment by tracking and installing the exact gems and versions that are needed and ensures that the gems you need are present in development, staging and production”

All you have to do when you start on a new or old project is execute the bundle install command in your command line and bundler handles all your dependencies. It checks the gems listed in the Gemfile and installs them accordingly. 


A style guide is a handy thing to have when developing on a project. As a developer you have a library of components to fall back on, designers and clients can see the individually , already finished components, hence can give feedback on live features and it serves as an overview of all building blocks from which the application will be built. In general they’ll document the conventions of the project and make the communication between different team-members, with different profiles, about project specific components a lot easier.

After trying out a few live style guides we landed on hologram, which is implemented into our new workflow. Hologram generates a live style guide based on comments in your scss files. It parses the assets of the project and looks for comments in a specific format and renders a static html style guide featuring all components defined by these comments.

styleguide comment format
styleguide html

You can reach te styleguide of your project by adding /frontend/styleguide/index.html behind your project url. 

Take a look at the styleguide of our demo-site here.

It's new, it's pretty, it's the new demo-site

Those beardy, hipster types amongst you will be happy to notice that our demosite received a complete makeover, gone are the space references and it now sports quite a lot of bicycles. We aimed to make the design fresher and offer a website which can be used for your project regardless of the context of the project.

It also comes boxed with a ready to use blog module and contact form, so in short it has all you need for a basic site.

demo site
demo site

Setting up a new project without the bells and whistles of the demo-site

Out of the box our demo-site is a pretty solid website, it rolls out with a bunch of features at your disposal, it’s also well designed and coded so, minus a few tweeks here and there, you’re set. But as awesome as it is, it’s pretty standardised so what if you have a design that asks things that are a bit more specific, or you need features that aren’t included in the default built? This used to mean that you’d have to write an overwriting code on top of our default styling. We ourselves found this a tenuous job. Cancelling out stuff you probably didn’t need in the first place is generally not a fun thing to do. We thought this was one of the main problems that needed to be addressed with the new version of our bundles.

You now have two options when setting up a new project, if you add the flag --demosite to the app/console kuma:generate:default-site command the default demo-site rolls out, when you run it without set flag you’ll get a very bare-bones version, ready to be customised as pleased. This devision is handled by adding if statements right into the twig, sass, … files of the generator bundle. 


Feel free to contact the author