How Task Runners can improve your dev environment

Development environments and build process are becoming more and more complex as we try to make developing faster, maintainable and scalable. As a developer, I want the computer to do the ‘heavy lifting’ as much as possible.

At one of our recent monthly developer meetings, I gave a lightning talk on task runners and how they could improve our front end workflow. I used GULP for my presentation, but the principle remains the same across any task runner.

Some typical tasks you may run are:

  • Compile SASS
  • Minify SASS
  • Minify JS
  • Concatenate/Uglify JS
  • Compress images
  • Watch for changes and run certain tasks on file change
  • Refresh the browser on file change

Quite a lot going on! For Content Management System websites, such as WordPress, you could install a plugin to do certain tasks for you. But doing it at the development stage gives you more control over your workflow, especially when your folder structure might be slightly different to what a plugin expects.

Writing your own tasks

What is great about these task runners, is that you can define your own tasks.

gulp-sass-example

In the task above, I am –

  • Creating a task called ‘sass’
  • Using the file ‘style.scss’ located in the ‘sass’ folder
  • Running it through the gulp-sass module, with an output style of compressed
  • Running it through the autoprefixer module
  • Saving the result to the root of the project (for WordPress it has to be in the root)

On the command line you would run this with ‘gulp sass’.
You can write as many tasks as you like, then comes the magic!

Task-ception

You can create a task, that runs other tasks.

gulp-build-example

Running ‘gulp build’ would run all 4 tasks together.

You could do something similar with the node ‘npm run’ command

npm-run-example

This has its own benefits of not even needing a build tool to run commands, most node modules can run from the command line. Personally, I prefer the layout of the gulp tasks but the point is making the computer do the ‘hard’ work for me.

Pros

There is a huge amount of power behind task runners, being able to automate your workflow can make the process much more fluid and flexible. You can create multiple tasks, batch tasks, development or production tasks, all to help make the process easier.

One of the great things about NPM is the package.json, which is a list of dependencies you would need to run the tasks. So if you are sharing your code with others, or even moving from one environment to another, you can clone the project and run `npm install` to get the required node modules.

Something I have come across, are issues with WordPress plugins, although they can be great and often are very useful tools I find they are usually aimed towards a certain workflow, rather than giving you the freedom. So by writing the tasks yourself, you can drop some of those minifying/compressing plugins you might have needed before. Another issue with WordPress plugins is consistency across environments.

At 1minus1 we tend to have >= three environments for one site; build, development, QA and live. Development could be multiple instances as there is likely to be more than one developer working on a site at a time. Making sure each has the right plugin installed, with the same version and settings is a bit of a pain. There are ways around this, like including the plugin as a part of your project repository, but the NPM package.json is a much cleaner way to do it.

Cons

A potential issue with using these node modules are that each one tends to have a lot of dependencies and could, potentially, be broken if it is updated or removed from NPM. These are rare issues and can be avoided with steps like creating an NPM shrinkwrap, which locks the versions of your dependencies, specifying which version of a module you need, or even hosting the module in its current version yourself.

Something else to consider is the deployment, will adding these tasks change the way you deploy? Rather than just needing a WordPress setup, you might also need node on the server to run the tasks when deploying, or will you need to include the compiled assets in the project repository? In my opinion, these are small issues but still worth considering.

With great power, comes great responsibility

Is it overkill? Instead of taking a hammer to a nail, did you get a rocket powered hammer, with racing stripes down the side to make it go faster, to knock that nail into next week? My point is, have you taken a fairly simple workflow and made it more complicated than it needed to be? I think it is easy to get carried away, which is why I tend to stick with tasks that are repeated on each project, like compressing images, styles, scripts etc.

If you have not tried using build tools in your development, why not try adding in some simple tasks, such as compiling your styles, to see how if it can fit with your workflow. You might be surprised.

Jonathan Hill wrote this awesome post, whilst catching pokemon