JSLint Utils A collection of useful bash scripts

One of the few tools that I consider truly indispensable when developing websites is JSLint. I love it. It makes my life as a webdev simpler and less prone to idiotic mistakes. Hitting the website to check changes to my scripts is, however, a huge pain in the ass. Hence, this project.

JSLint Utils is a set of utility scripts that wrap JSLint/Rhino, enabling linting on the command line, and automated reporting of linting errors via a continuous integration system like Hudson.

Usage: CLI

With Node.js (recommended) or Rhino installed, you can lint a specific JavaScript file or stylesheet from the command line by running:

/path/to/run-jslint.sh [FILE TO LINT]

If the file is clean, the script will output on stdout:

jslint: No problems found in good.js

If not, you’ll get a list of errors on stderr, and an return code of 1:

[error.js] Lint at line 1 character 1: 'x' is not defined.
x = "is not defined";

Usage: Hudson

Integration with CI systems like Hudson generally takes place via make files and XML dumps. In short, you’ll write a make file that lints all the files you care about, and dumps the results in a specific XML format into a directory. Hudson reads through the test results in that directory, and generates reports based on success or failure.

Before generating any test results, you’ll need to specify the basename to be used for the reporting. It makes good sense to follow the JUnit methodology here by using a reversed domain name as your package name.

Edit line 12 of jslint-to-xml.sh to specify your basename:


With that configuration out of the way, you can generate an XML report manually by running:

/path/to/jslint-to-xml.sh [FILE TO LINT] [REPORT DIRECTORY]

The file specified as the script’s first argument will be linted, and a report will be generated in the directory specified as the second argument.

Running against multiple files at once is generally best done via find. Take a look at the project’s Makefile for how I’d suggest that best be done. Make sure you configure the source and reporting directories by changing the relevant lines of the file, and it should Just Work™.

Hudson Configuration

In your Hudson project, you’ll need to do a tiny bit of configuration work in order to get linting running on an automated basis. Assuming you’ve already put a project together, you’ll need to do a few things:

  1. Add a new build step that runs make hudson in the source directory of your static assets. You’ll find this in the “Build” panel of the project configuration.

    Screenshot of the build panel in Hudson config

  2. Instruct Hudson to look for JUnit-style test reports by checking the “Publish JUnit test report result” box in “Post-build Actions”, and entering the report directory you’ve configured in the Makefile.

    Screenshot of the post-build panel in Hudson config

  3. Commit something, and watch while Hudson does it’s thing.

  4. Pat yourself on the back for a job well done.


Questions? Bugs?

If anything’s unclear, file a bug via GitHub or drop me an email.

©2010 Mike West: Project source is BSD licensed, and available on GitHub