Lessons Learned: Lint and JavaScript
Hi, everyone. This is James Shore with my lessons learned about Lint and JavaScript. We’re going to look at what linting is, how to use it, and how to incorporate it into your automated build.
What is “Lint”?
Lint tools read your source code and look for common mistakes. In JavaScript, this means things like missing semicolons or unsafe comparison operators. JavaScript is full of “gotchas” that silently introduce bugs. A linter is invaluable for keeping your code defect-free.
The leading linter for JavaScript is JSLint, by the famed Douglas Crockford. Now, Douglas Crockford can be a bit... curmudgeonly, and some people don’t agree with some of the choices he’s made with JSLint. They’ve forked JSLint to create JSHint. It provides more control over what’s flagged as an error and what’s not.
I chose to use JSHint for Let’s Code: Test-Driven JavaScript, but most of what I’m about to describe is equally applicable to JSLint.
Running JSHint Manually
The easiest way to run JSHint is to go to the website, paste in your code, and hit the “Lint” button. That’s fine for one-off scripts, but not really suitable for professional web development.
Another option is to use the Node package manager to install a copy of JSHint. (You’ll need to install Node first, if you haven’t already.) If you use the -g option when you install JSHint, it will put a convenient command-line interface on your path.
Automating JSHint
Personally, I don’t think the manual approach is a good idea. JavaScript has so many gotchas that you really need to run Lint all the time, as part of your automated build. And if it’s going to be in your automated build, you should install JSHint locally, not globally. That will ensure your build still works when other people check out your repository.
Once JSHint is installed, you can “require” it in your build script. JSHint and JSLint both provide the same interface, and it’s not a particularly friendly one. There’s only one function exposed by the module: JSHINT. It takes the source code to check, a set of options, and an optional set of globals, and returns true or false depending on whether the lint succeeded or failed. It also populates an “errors” array on the JSHINT function with specific error messages.
Processing Files
The first parameter is the source code. You’ll need to load your files from the file system. To load a file, use the readFileSync() function in Node’s fs module. readFileSync() reads an entire file into memory. It takes a file encoding; if you’re not sure what to use, UTF-8 is usually a safe bet. Once you have the file, you can pass it to JSHint.
Your automated build will likely have a list of files to check, so you’ll need a function that calls Lint for each file and collates the overall “pass / fail” status as it goes.
Options
The second parameter is an object containing your JSHint options. These options control what Lint complains about and what it allows to pass. They’re described in detail on the JSHint web site, so I won’t repeat that here.
Globals
The third parameter is optional. It’s an object containing your global variables. If you set the “undef” option to “true”, then JSLint will complain if you use any variables that haven’t been explicitly declared. This third parameter allows you to make exceptions to the rule. For each global variable name you include, you set it to “true” if your code is allowed to change the variable, or “false” if it isn’t.
Per-File Settings
You can also define options and globals by using a block comment at the top of a JavaScript file or at the start of a function. This is useful for changing your global JSHint options on a case-by-case basis.
Interpreting JSHint’s Results
When you run JSHint, it returns true or false according to whether or not your code passed. That’s enough to cause your build to fail when you need it to, but you’ll also want to print out the details of what Lint found.
To do that, you’ll want to examine JSHint’s errors array. Some elements of the array are blank--you can just skip those. The rest are objects with three properties: line, which is the line number; evidence, which is the source code containing the problem; and reason, which is Lint’s error message. Sometimes line and evidence are left out, so you’ll want to check for that.
Conclusion
So that’s what I’ve learned so far about Lint and JavaScript. To summarize, Lint is a tool for checking for problems in your source code. Given JavaScript’s “gotchas,” I think it’s an indispensable part of your automated build. You can use JSHint to include Lint in your build. Check out the source code for this episode for an example of how to do it. The link is available on your screen.
Thanks for watching, and I’ll see you next time!