WordPress JSHint Adventure

NOTE: I found this draft originally written on December 19, 2013.  Not sure why I decided it should remain unpublished, but I did and then like many drafts, I forgot about it.  So here it is.


One of the features of WordPress 3.8 is something that users will never notice. In fact, it’s something that most developers will never notice as well. It was establishing greater standards with the core JavaScript and adding JSHint.

JSHint is a tool that detects errors and potential problems with JavaScript code. They range from the annoying ( trailing whitespace ), to the potential bug inducing ( code in a function after a return ), to the likely to break a browser we still support ( a trailing comma in an object ). Adding JSHint was initially discussed around the same time as the creation of http://develop.svn.wordpress.org, but it wasn’t until the start of the WordPress 3.8 that much progress was made. K. Adam White led the effort to create the initial .jshintrc (which is the configuration JSHint uses) along with the grunt configuration to make running JSHint easy.

Once the configuration was decided upon, the process of fixing up the files was relatively quick and straightforward. A list was built and maintained of all files, and then edited to note the person who signed up to fix it and the ticket number.  Overall, from publishing the post until the last file was cleaned up it took 7 days.

By going file by file, we minimized the churn and made it simple for committers to review. It also made it easy to find bitesize chunks. Overall, 13 individuals wrote patches in addition to the committers who assisted.

Automating your front end development workflow

We all have a workflow. In fact, we all have many of them. Human beings are creatures of habit. In Thinking, Fast and Slow, Nobel laureate Daniel Kahneman describes our use of intuition to remember the steps in our workflows and the order of our workflows. When we wake up, we get out of bed, make our way to the bathroom, brush our teeth, perhaps shower and then make a bowl of oatmeal.

All of this comes naturally and we do it by thinking fast, by retracing the steps we’ve done hundreds of times before. We don’t slow down to think “Should I use the toilet or the sink”. We’ve trained our body to follow a workflow. We can do the same thing with our development workflows by taking some steps to understand how we work. We can then use tools to automate the repetitive tasks.

Continue reading Automating your front end development workflow