Thu 26 Aug 2010
Building JSLint Into Your Build Process (3 of 3)
This is the last in a series of articles that elaborated on a the incremental steps we took to address an issue with our JavaScript causing some last minute scrambling in our development and release processes. The last article finished with the de-linting our JavaScript, enabling us to have JSLint start failing our build.
The issue with our profile based solution of running JSLint, is that it wouldn’t fail the build as part of our test phase. To address this issue, we needed to write a plugin that we could tie in with the rest of our test phase plugins during the build. The easiest way to accomplish this is to write a small Maven plugin using Mojo. To help me with this task, I enlisted the help of Burke Webster whose Maven Mojo is much better than mine. Burke also wrote our Maven jstestdriver plugin . Building on Dominic Mitchell’s jslint4java, we wanted to keep the plugin interface as simple as possible. Here’s an example of properties for your pom.xml:
<properties>
<jslint.jar>${basedir}/src/test/resources/jslint4java.jar</jslint.jar>
<jslint.maven.plugin.version>1.0-SNAPSHOT</jslint.maven.plugin.version>
<jslint.options>browser,cap,debug,devel,evil,fragment,laxbreak,on</jslint.options>
<jslint.predef>RALLY</jslint.predef>
<jslint.source.dir>${basedir}/src/main/webapp/js</jslint.source.dir>
</properties>
These end up getting used in the build section for activating JSLint:
<build>
<plugins>
<!-- jslint -->
<plugin>
<artifactId>jslint</artifactId>
<version>${jslint.maven.plugin.version}</version>
<groupId>com.googlecode.jslintmavenplugin</groupId>
<executions>
<execution>
<id>run-tests</id
<phase>test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<jar>${jslint.jar}</jar>
<options>${jslint.options}</options>
<predef>${jslint.predef}</predef>
<src>${jslint.source.dir}</src>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
The jar tag allows you to specify where your jslint4java jar is. The src tag allows you to specify the root of your JavaScript (where the plugin will begin to recursively look for JavaScript files on which to run JSLint). The predef tag allows you to inform JSLint of certain “global” variables that should be predefined so that JSLint will not complain. This is handy for setting up things like namespaces. The options tag is where you pass JSLint options to JSLint. Any of the options available for JSLint are valid. There is a skipTests tag that you can set to true to skip the next phase of tests. There is also a verbose tag to have the plugin tell you what it is doing in more detail.
With the JSLint Maven plugin, JSLint can now fail the build. We also set up some profiles to run JSLint on portions of our JavaScript in different modules and in conjunction with other testing frameworks like jstestdriver. Deveopers benefit by being able to more easily run JSLint.
For the 8 weeks this has been in place, JSLint has kept numerous problems from reaching our committed code base, and when a error slipped past JSLint, Hudson told us right away of a problem. We haven’t had any last minute fire drills due to the same JavaScript issues and we have happier development and operations teams.
