JSLint UtilsA 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.
/path/to/run-jslint.sh [FILE TO LINT]
If the file is clean, the script will output on
jslint: No problems found in good.js
If not, you’ll get a list of errors on
stderr, and an return code
[error.js] Lint at line 1 character 1: 'x' is not defined. x = "is not defined";
Integration with CI systems like Hudson generally takes place via
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
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™.
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:
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
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
Commit something, and watch while Hudson does it’s thing.
Pat yourself on the back for a job well done.
Added the ability to opt into my fork of jslint, which
fixes a few behaviors that I see as bugs. Just type
/lib/vendor directory to pull down the latest version
of my fork, and rebuild the node/Rhino bridges.
Added support for Node.js as an alternative to Rhino. It’s astounding how much faster things go when you don’t have to load Java on every execution.
Cleared up the project’s licensing. BSD, all the way.
Initial public release.
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