This is the first post of a five part series looking at WordPress plug-in/theme development with Grunt.
- Grunt & WordPress development
- Grunt & WordPress development II: Installing Grunt
- Grunt & WordPress development III: Tasks for internationalisation
- Grunt & WordPress development IV: Another task for internationalisation
Back in August the WordPress core team announced they were going to use Grunt in WordPress’ development. This in my view is a major stride forward for WordPress (more so than the much celebrated ‘features as plug-ins’ – which itself marked an improvement to WordPress’ development cycle).
This series of articles however, will be focussed on using Grunt for WordPress plug-ins and themes (which are fundamentally the same thing), and the tasks I use in development. In this first post I’ll discuss the what and the whys:
What is Grunt?
(Once Grunt is installed) there are two files which set up Grunt for use in your project:
package.json– which details your project (in this case: a WordPress plug-in) and it’s dependencies (in this context, Grunt and any Grunt plug-ins you want to use).
Gruntfile.js– listing the tasks you wish to perform and their configuration
Those tasks can be executed simply by running
grunt [task name]
in your command line. You’ll probably have multiple tasks that you’d want to run one after than other (e.g. one task to copy/generate files from your development environment to a build directory, and another to upload that directory to an Amazon S3 server). Instead of calling each manually Grunt allows you to create tasks which simply call a collection of other tasks. For example
might be configured to trigger unit-test and linting tasks.
The idea of automating deployments, unit testing, compressing images, scripts & stylesheets and other tasks you may wish to perform in your plug-in’s development, build and release cycle is certainly not unique to Grunt. Before I switched to Grunt I had a home-grown
Makefile to perform a lot of my routine tasks.
Grunt however, brings this all under one roof: giving a familiar command line procedure to execute task(s). Importantly it allows (Grunt) plug-ins, and their end-users to add structure to their tasks. By this I mean tasks being able to call other tasks, being able to initiate an entire list of tasks, being able to configure all your tasks in only one file and easy of portability. In fact, if you download a development repository for a plug-in which includes the
Gruntfile.js files, in one command you can install all the Grunt plug-ins it requires for use in testing, building and deploying that plug-in. (This assumes you have Node.js installed, which I’ll cover in part two).
Grunt doesn’t offer much new – but it does offer a much better solution.
The point is: it has a large, and growing ecosystem. In the majority cases, for any task you might want to perform, there will exist a grunt plug-in to perform it.
And if there isn’t? Grunt is incredibly well documented, open-source and easy to dive into. If you find a gap in its armoury, the chances are it’s easy enough to fill.
If you weren’t already sold on Grunt, hopefully that will do it. The next post will be on installing Grunt and executing your first task.