Grunt like a Pro

Tools are great, tools save us loads of time, we should all have loads of tools, the best tools… then we’ll be super fast and amazing at our jobs.

Or, perhaps we’ll just look like we’ve good at our job and secretly in the dark of night, hack away, inventing strange new forms of tool abuse to somehow merge together our ideas into a working prototype which does not collapse if the wind blows above a gust!

So – yes, tools are great and the internet is awash with many amazing tools, many of which are free – at least up to a certain tier-level or usage quota – but we don’t need all the tools, we need the right ones 🙂

In the limited scope of WordPress Application development, a common task is building a release – this is a task analogous to wrapping a birthday present or even preparing a meal – we need to clean up all the mess, make sure that we’ve removed the price tickets and hidden anything else that we don’t want the recipient to see or know about – be that for security, performance or any other reason.

Luckily, the Open Source economy is built upon the value of ideas, not secrecy – this is priceless, it offers a stepping stone for new developers to view the work of grand masters, to pick it apart, fork at it and to extract and re-user whatever they feel like from it – of course while respecting all license terms and give clear attribution – give credit where it is due.

Task Runners

Most people these days realize the benefit of leveraging the processing power of modern computers to churn over their data and spit our calculations for them – the same is true, if perhaps taken to a more technical level by software developers – who write the tools that people use to churn over their data 🙂

In the typical flow of building WordPress applications, we have a set of tools known as Task Runners – tools which we can give a defined list of tasks to deal with when certain commands are issued of events happen – there are many available options, and we use GruntJS – which is available as an NPM package and runs on NodeJS

If all those terms are new to you, then take some time to review the links and familiarize yourself with the concepts – in short, we’re freeing our creative minds by outsourcing repetitive, but important tasks, to tools which we can set-up to run exactly how and when we need them.

NPM loads all configuration options from a file called package.json – typically this sits in the root of your application and is updated each time you run commands to install new packages – below is a typical package.json from one of our projects:

JSON is a data interchange format which has been embraced by many tools, including WordPress, as the standardized format with which to exchange data and common configuration settings – it has designed limitations – such as not supporting comments – but those are part of the reason its use has become so widespread.

The Package.json file contains data about which NPM package are installed, which build steps they are connected to and also generic data about the project and commands which we can run in Terminal to control packages.

In the example Gruntfile below we show how to load JavaScript and SCSS files from a source location, concatenate, minify and create source maps for debugging ~ making sure everything we need is correctly formatted and located in the public asset directory.

Things to note:

• This example is for a Grunt Hub setup – see below – so all node_modules are located in one single location above the root of the application
• All configuration options are defined before the tasks – and referenced using variables such as <%= config.uglify.theme.dest %> – this is easier to manage and keeps all configuration in one place, ensuring that it remains consistent.
• We use the sass option includePaths to define the root directory to compile from – this means we can cherry-pick files from certain locations, but keep other areas out of bounds.
• We store additional configuration options – in this case a list of absolute paths to JavaScript files which we want Uglify to process – in an additional json file, which we can access from inside the Gruntfile using 'q_modules': grunt.file.readJSON('q.module.json') – this allows us to access the data object inside the json file.

Multiple Gruntfiles

What about more complex projects which might include sub modules which all need to be configured to build at the same time? There is of course a tool for that also – NPM offers GruntHub.

“A Grunt task to watch and run tasks on multiple Grunt projects.”

This means that we can place individual Gruntfiles in each sub module and control them all by issuing terminal commands from the root of the application project – the set-up is initially more complex, but once you get accustomed to it, you will find that it offers granular control, and of course you can still step into the root of each sub module and run commands individually on each project, if needed.

Here is an example root level Gruntfile when using GruntHub:

Note the listed commands at the top such as npm run q:deploy, these are defined in the Package.json file and can be issued in Terminal to start GruntHub processes.

"scripts": {
    "q:dev": "grunt hub:all:watch",
    "q:deploy": "grunt hub:all:deploy --verbose"
}

Note that you can you can append options to CLI commands in the same way that you would if running them on individual projects – in this example we don’t need verbose feedback on standard development tasks, but we do want to ensure we can locate issues correctly on deployment builds.

We also use the package logfile to write feedback to a file, where is it more easy to study and locate problems, rather than trying to read a moving target in the continually scrolling terminal UI – the following command includes the package and defines the log file location.

require('logfile-grunt')( 
    grunt, { filePath: './wp-content/gruntfile.log', clearLogFile: true }
);

What data is logged depends on the individual options for each task, we also clear the log on each run with the clearLogFile option.

Next Level

Once we start looking at the parts of our work that are both repetitive and perhaps dull, we quickly find many redundancies – and there is no better recipe for mistakes than creative minds trying to focus on repetitive tasks – instead, we can focus our minds on the more interesting challenge of correctly setting up a task runner and let them deal with the monotony of carrying out the actual work.

Many people worry that they might lose their job to a robot, but the risk is mitigated by the knowledge that we are creative, given the chance – we are programmed to solve problems and find elegant solutions to complex challenges.

On a daily basis we have already outsourced a huge amount of our daily logistics to the robots we carry in our pockets – in many cases our connection to technology has become a highly intimate relationship  – so why not get with the times and embrace Task Runners as part of your development process 🙂