In Thoughts

Learning & Working with Grunt

Aaron Mcguire is a graduate web developer looking for full time opportunities after finishing a successful 8 month placement at Supremo. See his portfolio at aaronmcguire.co.uk

One thing I will always be thankful for during my time spent at Supremo is being introduced to JavaScript Task Runners more specifically Grunt. If you’d have asked me 9 months ago what Grunt or Gulp was I would have probably given you a blank look. Now though I can confidently setup, configure and integrate Grunt into all of my projects, in fact I don’t think I’ve started a project in the past year that didn’t involve Grunt somehow. So It seemed worth compiling some of what I’ve learned into a blog post.

What is it?

Grunt as their tagline says is a JavaScript Task Runner. It’s simply used for automation of redundant tasks, be it compressing images, concatenating files or even synchronised browser testing. Grunt boasts a huge ecosystem with hundreds if not thousands of plugins available, so it’s one hell of a tool to have on hand.

What problems did I face?

Obviously it wasn’t all smooth sailing there were a few problems faced. When starting out it was confusing that all dev dependencies were stored in a package.json file and all configurations and tasks were done in my gruntfile. This was a minor learning curve and it’s something you just end up getting used to – much like the grunt-cli commands. After going a little further with Grunt creating custom sets of tasks for different scenarios e.g. build, dev and imports I started to notice a lot of time being wasted scrolling through my gruntfile.js trying to find each task to configure. This process became tedious and once the gruntfile started to fill with more and more tasks it became almost unmanageable.

So what did I do?

Deciding that the current structure of my Grunt was no longer maintainable, I found a solution that would allow me to store my tasks and configurations in separate folders and each to their own file, meaning a tidier much more efficient working structure. This was achieved via the use of two Grunt plugins. The first was jit-grunt or Just In Time Grunt. This plugin automates loading in your NPM tasks meaning you don’t have to loadNpmTasks every time you use a new plugin it also doesn’t slow down your tasks, regardless of how many plugins you’re using! The second plugin is load-grunt-config which works asynchronously with jit-grunt. This plugin allows you to separate your task configurations into separate files then integrated with jit-grunt, allows you to define a custom task directory allowing each set of defined tasks to be generated into separate files (or just the one for smaller projects).

So my grunt file went from housing all configurations, tasks and loading in each NPM task to being 10 lines long. Now whenever I need to change some task configurations I simply go to the config folder and select the file – saving countless hours trawling through a collection of configurations and tasks.

Code Snippet

Obviously, this isn’t all I learned about Grunt but it stands out as being something worth sharing.

Aaron Mcguire is a graduate web developer looking for full time opportunities after finishing a successful 8 month placement at Supremo. See his portfolio at aaronmcguire.co.uk