Finding and Fixing JavaScript errors with JSHint

The JavaScript Coding Standards have been updated, so it’s time to move on to tackling our JSHint errors!

JSHint is a tool to check for errors in JavaScript code. As was discussed last week, we’re kicking off a small effort to work through our core JavaScript files. To get through the errors revealed by JSHint as quickly as possible, we’re following the model established by the Inline Docs team and posting a list of files with issues so that people can “claim” the files they’d like to fix!

At the bottom is a list of every file in core that is displaying JSHint errors. Files with a checkmark have been patched and should now be passing lint. Files marked with (@username #xxxxx) are already claimed, and being worked on.

Please read and understand the process we’ll be following to address these issues! Many thanks to @azaozz, @nacin and @jorbin for helping identify the safest way to approach fixing these errors, and to @rzen for posting the Inline Docs article on which we based this guide.

How to contribute:

  1. Leave a comment on this post with the file* you’re about to edit (check the list first to make sure it hasn’t already been claimed).
  2. Update your local WordPress SVN to the latest version of WordPress trunk (currently 3.8-alpha).
  3. Create a new ticket on Trac for the file.
    JSHint-related trac ticket settings

    • Format the title as “jshint shouldn’t throw errors – path/to/file.js”.
    • Assign the ticket to the “Build Tools” component.
    • Make sure your email is stored in Trac’s preferences

    If you are logged in, you can click this link to automatically open a ticket with the right settings.

  4. Edit the file, and make a patch. Please make sure you create the patch from the root directory of your WordPress SVN checkout. If you are working on a large file, consider making multiple patches for each type of change.
  5. Upload your patch to the Trac ticket you created, and add the keyword “has-patch”.

*Note: We strongly encourage you to work on one file at a time. These shouldn’t take very long, but if you call a bunch at once and get tied up, we won’t be able to get through these as quickly as possible. To quote @rzen from the inline docs effort, “your edits should be made and patched swiftly so that they aren’t invalidated by (or don’t invalidate) another patch.”

Keeping Discussions Focused:

Any discussion about the specifics of a patch itself should happen on Trac. Discussion about the overall effort should take place during our standing weekly meeting, on Wednesdays at 1900 UTC in #wordpress-dev*.

Files needing patches:

Checked files are now passing JSHint

See all open tickets in the Build Tools component

For tips on dealing with global variables, inlined third-party code within first-party scripts, etc, see the JSHint tips in the JavaScript Coding Standards

For the curious, this list was created with a jazzy little command @nacin came up with to pipe Grunt output through ack:

grunt jshint --force | ack '^Linting src/' | ack -o 'wp-.*.js' | sort | uniq -c | sort

What we’re NOT doing

The two JSHint options called out in the earlier post, “curly” and “eqeqeq,” would ordinarily make up the vast majority of the errors JSHint reports in our files. We’ve currently set Grunt and JSHint to ignore these two types of errors when JSHint is run against core. While these are best practices, we’ll come back to them once we address the more significant code smell issues like undefined variables.

Also note that we’re not tackling whitespace or non-JSHint-related refactoring during this effort. We’ll get there, but we have to mitigate the risk to core as much as possible so we don’t interrupt the 3.8 cycle. Keep your changes focused on passing JSHint this go-around.