Download the code from GitHub : Current version 1.0.0

Update 04/01/2013

This plugin is now available on the Jenkins update center, so can be installed through the Jenkins plugin manager.

JSLint plugin for Jenkins

Coding standards are essential at Box UK. We use JSLint to check our JavaScript in all non-legacy projects (and have even added it to some legacy projects where the scale was not prohibitive). We’re all about automation here, so here’s how we went about getting JSLint into our builds!

Initially we started out running JSLint on commit, but there are several reasons we switched to running lint in Continuous Integration (CI):

  • Having JSLint run as part of a CI job alongside our other checks makes it easier to track quality progress, particularly on legacy projects.
  • We work on lots of projects and don’t want to have to set up the hooks on every single repo.
  • We use Git for newer projects so any repo hooks we build for Subversion would have to be recreated for Git.

First steps in Jenkins

The backbone of our production floor is the Jenkins CI Server – every project has at least one job that runs on commit. Therefore, early on in our journey into automation, we started linting Amaxus 4. All we did was run a shell script that triggered Rhino and output to the regular console log. We then used Jenkins text finder to scan the logs and see whether JSLint had returned a clean bill of health. If not, the build was marked as “Unstable”.

Well, this was working, but only for Amaxus, and here came problem set #2:

  • It wasn’t transferable to other projects.
  • It was clumsy – devs had to read the console logs to find the failing lines. I ended up being “build monkey” a lot of the time, going through other people’s build logs to tell them why we had a red build on the wall.
  • We couldn’t track progress over time.
  • All our build slaves needed Rhino installed

Looking for options

We’d made progress, but we didn’t feel it was easy enough to integrate JSLint into a build. So, we looked at options:

  • Violations plugin: this initially looked good – it takes JSLint output, presumably the raw console output. However, we didn’t go with it because we’d still need some way of running JSLint. Because we have to be able to run Rhino or Node, this meant our slaves would have extra dependencies in their Puppet manifests.
  • JSLint4Java.jar via Ant: this looked promising but it required Java on the slaves. Furthermore, our version of JSLint is slightly modified from the “official” Douglas Crockford version, and I couldn’t find an easy way to specify our in-house JSLint fork.

Building a plugin

We’d made a few plugins for Jenkins – particularly our Amaxus plugin which allows us to set up a customer’s CI process including PHPMd, JSLint, PHPCodeSniffer and PHPUnit in less than a minute. It seemed logical to build a Jenkins plugin that produced logs that we could integrate into the build results. I toyed with the idea of JUnit format output but then plumped for a Checkstyle format – after all, this isn’t a unit test.

Firstly, our modified version of JSLint outputs to Checkstyle format. There were some difficulties with this initially that we had to overcome:

  • Our early versions of the plugin required Rhino to be on the box. This wasn’t really acceptable as it added a dependency. Thankfully, you can bundle it into the pom.xml. This however had a knock-on effect that our jslint.js no longer worked – when not being run from the command line, Rhino doesn’t have readFile, writeFile or print functions available. Thankfully, it was relatively easy to add wrappers that call equivalent Java functions - we just added them to our JavaScript file. Perhaps not the most elegant solution, but it doesn’t introduce dependencies outside Java.
  • While the plugin worked fine on a single Jenkins instance, once we started to run it in a master/slave configuration it threw exceptions saying it couldn’t serialise the builder. This was fixed by using the launcher and extracting our LintRunner functionality into a Callable class. See this Stack Overflow thread for more info.

Up and running

So, here is our plugin’s results page. We’ve found it really useful to have the information right there in the build report!

JSLint Checkstyle

How did I get it?

Head over to to get the plugin, and clone away!

You’ll need Apache Maven installed to build it. Just type “mvn” in the project root and it will output an .hpi file in the target directory.

You can then install this plugin by going to the plugin manager in Jenkins and uploading it:

JSLint Install

You can then go and set up a job like so:

JSLint Config

What's next?

As mentioned earlier, we made a bunch of modifications to JSLint for our requirements. Since we did that, JSLint has been forked to the less opinionated JSHint so we might switch to that at some point.

Right now, this plugin is only set up with the JSLint options that constitute the Box UK JavaScript coding standard. The plugin should add options exposing the JSLint options. Maybe we’ll do it ourselves, but feel free to get involved on GitHub!

To stay up-to-date with the latest tech news and views, be sure to check out our weekly tech round-up posts - and sign up to our mailing list to have them delivered direct to your inbox.

About the author

Box UK

Box UK

Box UK's team of simply brilliant thinkers, consultants and application developers mastermind simply brilliant solutions to the world's toughest, performance-critical web and software assignments.


Bruno P. Kinoshita

Jul 19th, 2012

Hi there! Nice work, I saw the announce of the plug-in in Jenkins dev-list, and found the link for this blog post. Very well written post, and probably I will use this as reference when blogging about a plug-in hahaha. Hope you don't mind, I will make sure to credit BoxUK :-) Thanks for sharing this plug-in, keep up the good work lads. Cheers, -B

Box UK

Jul 20th, 2012

Thanks Bruno!

Box UK

Dec 19th, 2012

We have just enhanced this plugin so it exposes all of JSLint's options :-) You can now, for example, pass in -Dadsafe=true, -Dcontinue=true, or specify a global set of things that are predefined with - Dpredef=foo, bar, baz. The plugin has onscreen documentation explaining this stuff, it's very easy though! Added as of tag 0.7.2. Would be cool to get this into the repos so others can easily install it without having to compile themselves - I'm working on that now!

Box UK

Jan 4th, 2013

This plugin is now available on the Update Center so can be installed through the Jenkins plugin manager! It also has a page on the Jenkins Confluence wiki

John Smith

Mar 28th, 2013

Just an observation: this plug-in can only be used if you set a new Jenkins "free-style project" and select a JSLint build step. This means that I can't add Javascript violation checks to my existing Maven projects :-(


Apr 27th, 2013

Thanks for this plugin! One remark however, this plugin uses a jslint.js version which is quite old (3 years), compared to last jslint.js from Douglas. Do you intend to upgrade the bundled version of jslint.js (I hope so), or switch to jshint? Thanks again for this plugin

Box UK

May 29th, 2013

Hi Jerome, we're not planning to update to a later JSLint at present, but feel free to submit a PR! The version of JSLint that is bundled is somewhat modified, so any modifications would need taking over, either that or some refactoring done. Thanks,


Aug 8th, 2013

I have your latest plugin and the latest checkstyle plugin running on the latest weekly Jenkins (1.5256). Your plugin runs great and I do get the list of errors, but when I click on the details tab on the Checkstyle page, I see: foo2.js:69, , Priority: High Line too long. No description available. Please upgrade to latest checkstyle version. foo2.js:101, , Priority: High Line too long. No description available. Please upgrade to latest checkstyle version. Any ideas?

Box UK

Aug 9th, 2013

Hi Shannon, That's actually the behaviour I get also. Unfortunately there's no away to get rid of that checkstyle nag that I know of. You should be able to click through and see the exact line number. I think it's because it's not an error code that is known to Checkstyle, so it's only a warning and can be ignored. Thanks, - Gav

Alexader Jeyaraj

Jan 18th, 2014

Nice plugin, exactly what I needed. However I am facing an issue with passing "Arguments". I want to assume NodeJs, so in the "Arguments" field I gave -Dnode=true, however it has no effect on the result. I am using 0.8.2 version updated from the Jenkins plugin manager.

Jan 24th, 2014

Hi, thanks for the great work. I have the same problem as Alexander. I can set -Dpredef=foo,bar okay but -Dundef=true doesn't work for me. User error or not implemented yet?

Jan 24th, 2014

D'oh. Of course predef is negating the undef isn't it. I really just want to make it agnostic about what order my functions are declared in, which isn't the same thing as ignoring all undeclared variables at all.


Mar 6th, 2014

Hi, I have a problem with a few JSLint options that doesn't work : -Dplusplus=true-> there ar still warning in the Checkstyle report it's the same with -Dwhite=true. Some others options seems to work correctly.


Apr 15th, 2014

Same here: plugin arguments are ignored

Raine Ng

Jun 16th, 2014

The last image is currently missing now

Emma Willis

Jul 16th, 2014

Hi Raine, thanks for letting us know about the image - it should be showing correctly now.

Estelle Battu

Aug 6th, 2014

The last image is not readable, and I can't click on it to enlarge it.


Aug 27th, 2014

The Job Configuration image is not readable. Can you please post a better screenshot which is useable. Thanks, Sudhansu

Emma Willis

Aug 27th, 2014

Hi Estelle and Sudhansu, if you click on the image now you should be able to access the full-size version. Please let me know if you are still having issues, Regards, Emma.


Aug 27th, 2014

Thanks Emma. But the arguments section is not there in the enlarged picture which was of most importance. Can you please attach the same. Regards, Sudhansu

Emma Willis

Aug 27th, 2014

Hi Sudhansu, unfortunately I can't find the original of that image but you may be able to find the information you need here:


Aug 27th, 2014

Thanks Emma, This one is also helpful. Regards, Sudhansu


Mar 5th, 2015

My build was successful. It is showing warning only. If i click that warnings it is not redirecting to that file contains the warnings. How can I do that? Can anyone please help? As well as the output file also does not contain any content. I gave log file name as builddirectoryname/.../log.xml.

Add Your Comment

Related content

We're hiring. Let's talk. View available roles