Since introducing Grunt into my software development last year it’s not an exaggeration to say it has revolutionised many of my processes. At work we use Grunt throughout the SDLC but our first adoption was for our JavaScript and CSS, and after building websites with Grunt for well over a year, it is now integral to the front-end development of several key projects. In fact those projects that don’t use Grunt now seem outdated.

Over time I’ve experimented with many tasks and even written my own and it’s this experience that has enabled me to produce this top five list of our essential front-end Grunt tasks (I’ve cheated a bit with the counting).

1. CSS preprocessor

Take your pick between Sass and Less (or the little brother Stylus) but a CSS preprocessor is de rigueur these days. I often chose Less and use the lessThemes task to automatically compile our files into themed stylesheets.

What this means is I create individual theme files with different values for each variable, e.g. theme-uk.less and theme-com.less where the @font-family variable is Arial for the UK theme and Verdana for COM. The lessThemes task simply outputs two CSS files, one for each theme.

If you don’t use themes grunt-contrib-less will do nicely and will output just the one CSS file.

2. Concat / CSSmin / Uglify

They may not realise it, but your visitor wants to download the smallest (and fewest) assets from your site, so a single compressed stylesheet and a single compressed JS file is what you should give them. But these are the last things you want to have to maintain as a developer so you’ve probably already split your CSS into multiple files, each one likely defining a specific section of the page such as header and footer, or typography or a component such as search-box.

Concat takes a folder of individual stylesheets or JavaScript and merges them into a single file. CSSmin minifies this file, removing white space, uses shorthand and making other space saving changes while the JS equivalent, Uglify obfuscates your JavaScript, removing white space and shortening variable and function names.

3. Imagemin / SVGmin

Again, this is all about page performance – optimizing your images into the smallest viable file size.

Image optimization has been around for a while, but as a manual task it is easy to either forget, or just do once, omitting any new images created subsequently. Adding it to your build process with Grunt is just one less thing to do in your quest to produce the fastest website – but as always with image compression you should manually select the settings that don’t compromise quality for file size.

Imagemin compresses .jpg and .png files, while SVGmin does the same for SVGs.

4. JShint / CSSlint

I’ve heard criticism of linting, and I agree that the tools that blindly enforce all rules aren’t doing their job properly, but they’re very effective when you understand the rules and can pick and choose those with which you agree.

The linting tools we use for CSS and JS (CSSlint and JShint) are easy to automate with Grunt, giving you and error when any of your house conventions are broken – invaluable in a multi-team engineering department. I don’t run these lints every time I change a file, but once before deployment is a handy safety net.

For both grunt-contrib-csslint and grunt-contrib-jshint we define our rules in external .csslintrc and .jshintrc files in the root of the project.

5. Watch

The watch task is invaluable when using a CSS preprocessor – you can’t use Less or Sass and afford to not Watch.

This task simply monitors a file or folder and if any files are modified it runs another task; in our case we watch the Less files and recompile to CSS when any changes are made. Be careful though to exclude generated files else you’ll be stuck in a loop.

If you want to take your productivity to the next level use the livereload option in Watch that reloads your browser when a change is made. All you then need to do is edit a file and boom, the change is in front of you and you’ve not had to hit F5.