Software Engineering in WordPress and Musings on the Deep Life

Using CodeKit For WordPress Plugin Development

Earlier this week, I shared my approach to and the tools used for building a WordPress Plugin. In the post, I briefly touched on CodeKit, but I didn’t really talk about why I use it nor did I share how I configure it for my WordPress-based projects.

Using CodeKit For WordPress Plugin Development

CodeKit is a platform-agnostic application – it’s meant for anyone who is doing web development – and it has been one of the single best tools that I’ve added to my WordPress toolbox in the past year.

The thing is, there’s a variety of ways to tailor CodeKit for your needs. It has support for LESS, Sass, a couple of JavaScript linting utilities, dependency management, minification, and so on.

Though there’s no single “right way” to configure it, here’s how I’ve been using CodeKit for WordPress plugin development.

On File Organization

Before dropping my project into CodeKit, I start with a boilerplate directory structure:

Using CodeKit For WordPress Plugin Development - On File Organization

In the screenshot above, you’ll notice that I maintain separate directories for CSS and for JavaScript. Within the css directory, I have a less directory and within the js directory, I have a dev directory.

Obviously, I use LESS to write CSS, but the less directory serves as my working directory. Any stylesheet that resides in the root of the css directory is generated by CodeKit.

Similarly, all of my JavaScript is written in the dev directory – CodeKit combines, minifies and outputs the final version of the files into the root of the js directory.

This means that when I enqueue and register stylesheets and JavaScript, I use the files that are located in the root of their respective directories – not what’s located in the working subdirectories.

Again, all of the files in the root of these directories are generated and output by CodeKit.


Obviously, I use LESS but I’m not one to take a strong stance on why you should use it (or why you shouldn’t use Sass). I like LESS so I roll with it.

I’ve configured CodeKit to use it’s internal LESS compiler, to minify the file, and to run Bless on the file once it has been compiled:

Using CodeKit For WordPress Plugin Development - Less Options

Since all of my LESS files reside in a subdirectory of the CSS directory, I set CodeKit to write out the compiled files to the directory above where the LESS files are stored:

Using CodeKit For WordPress Plugin Development - Less Output

And that’s it for the LESS configuration. Easy enough.

JSLint For JavaScript

For JavaScript, I’ve set CodeKit to concatenate and minify all of the JavaScript sources:

Using CodeKit For WordPress Plugin Development - JavaScript Settings

Since dev is my working directory, I’ve set CodeKit output the file in the root of the js directory:

Using CodeKit For WordPress Plugin Development - JavaScript Output

Finally, I’m a big fan of Douglas Crockford – his book JavaScript: The Good Parts – is what really changed the way that I write my JavaScript source. I consider that book the be to JavaScript what K&R did for C.

CodeKit offers two ways to evaluate the code quality of your JavaScript – JSHint and JSLint. JSHint is a nice tool and is slightly less strict that JSLint, but JSLint is written and maintained by Douglas Crockford so I’ve opted to use this particular linter in my projects.

Since the JavaScript is based on jQuery, I’ve had to make a couple of customizations to the JSLint settings:

Using CodeKit For WordPress Plugin Development - JSLint Settings

This will prevent CodeKit from generating JSLint errors for globals that it doesn’t recognize or that it considers undefined.

For the most part, that’s it. All of the settings are configured at the global level so they are applied across the board to each my projects. By using a standard directory structure for organization and a global configuration, it’s really easy to get up and going with new projects (and even converting existing projects).


  1. jbrad70

    Thanks for posting this Tom. I have been having good luck using Codekit for some rapid prototyping with Bootstrap and LESS and was hoping to start using it for creating some WordPress plugins. Codekit #FTW

    • Tom McFarlin

      Yep – it’s solid and when you can nail down the parameters and configuration you like along with a good source control setup, it’s hard to beat.

  2. wpreader

    Great article tom – i always enjoy reading the general workflow of other devs!

  3. Björn Kahlert

    I have the problem that the auto-refresh feature for less/css does not work using WordPress + CodeKit.
    I mailed the developer of CodeKit (Bryan Jones ).
    He told me that this is due to elements at the end of the which is against the specs.
    I wrote a small WordPress plugin that deletes those elements et voilà it worked.

    So I asked Bryan if he could fix the problem by allowing elements also to be in the .
    He refused since this is against the specs – ignoring that this is common practise. In WordPress this behaviour can be even triggered using wp_enqueue_script + $in_footer = true.

    It’s frustrating. You can only change all plugins that don’t meet the, catch all the output and rewrite (performance penalty!) or use an alternative to CodeKit.

    • Tom

      Yeah, I understand what you’re saying.

      I don’t fault Bryan for sticking to the specifications, to be honest. I don’t even really use the autorefresh feature because it doesn’t tend to work well with my workflow, but I totally see how that could be problematic for those who do.

      At least you’re able to write a plugin to help mitigate it. I think that’d be useful for some people who are experiencing the same thing that you are.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

© 2023 Tom McFarlin

Theme by Anders NorenUp ↑