I often find myself wasting a lot of time debugging a mysteriously failing Jasmine spec, only to find the root cause being some missing semicolon, the accidental use of double-equals equality or some similar Javascript eccentricity hiding inside my code. On my current project we had been using JSHint through the jslint_on_rails gem to lint our Javascript as part of our test suite, but the unfortunate part of that is that it’s outside of our normal TDD cycle, functioning more like a style enforcer than something that can actually help you find bugs.

To help with getting more instant feedback, I wanted to see if we could get JSHint to run against our code from within the Jasmine test suite itself. I came across this blog post from Brandon Keepers describing how he does exactly that.

One gotcha I ran into was that I had a number of global objects defined in my specs both by Jasmine and several libraries we were using. JSHint defines some options for whitelisting common globals in its docs under “Environments”, but does a poor job of explaining how to whitelist additional variables. I discovered that by passing an object literal of globals as a third argument to the JSHINT function, I could exempt these from definition warnings.

A partial list of ones I’ve so far found handy:

var globals = {
   _: false,
   _V_: false,
   afterEach: false,
   beforeEach: false,
   confirm: false,
   context: false,
   describe: false,
   expect: false,
   it: false,
   jasmine: false,
   JSHINT: false,
   mostRecentAjaxRequest: false,
   qq: false,
   runs: false,
   spyOn: false,
   spyOnEvent: false,
   waitsFor: false,
   xdescribe: false
};