Tue 10 Aug 2010
When JavaScript Makes Your Scrums Scramble(1 of 3)
Recently we had some issues with our JavaScript which were discovered late in the release cycle. This caused some scrambling in our development and operations teams at the last minute. In both cases, the culprit was an extra comma which causes IE* to have conniptions, while FireFox, Chrome, and Safari seem to be immune. This is the first in a series of three articles that describe the incremental steps we took to address this issue. This first article describes what we did to assess the situation. The second article describes the steps we took to de-lint our JavaScript. The third article describes a Maven module we wrote to allow developers to run JSLint on their JavaScript changes, pre-commit, and also allowed our Hudson jobs to fail the build should JSLint find a problem.
To eliminate the fire drills and get feedback earlier (at the build phase), we implemented Douglas Crawford’s JSLint to check all of our JavaScript as part of the build process. We have several sub modules within our code base; each submodule with its own JavaScript. We wanted developers to run mvn tests before committing changes and to have our Hudson jobs fail if JSLint found any problems.
To try to get a handle on how big an issue we could be looking at, I created a maven profile to run Dominic Mitchell’s jslint4java as an ant task within our pom.xml:
<!-- run the jslint4java on javascript test, mvn -P jslint-all test -->
<profile>
<id>jslint-all</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.4.2</version>
<configuration>
<skipTests>true</skipTests>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.3</version>
<dependencies>
<dependency>
<groupId>com.googlecode.jslint4java</groupId>
<artifactId>jslint4java-ant</artifactId>
<version>1.3.3</version>
</dependency>
</dependencies>
<executions>
<execution>
<id>run-tests</id>
<phase>test</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<ant antfile="${basedir}/jslint-submodule1.xml">
<property name="root" location="${basedir}" />
<target name="jslint" />
</ant>
<ant antfile="${basedir}/jslint-submodule2.xml">
<property name="root" location="${basedir}" />
<target name="jslint" />
</ant>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
I also had to create an ant build file to be able to set the options for jslint. Our initial one looks like this:
<project xmlns:jsl="antlib:com.googlecode.jslint4java">
<target name="jslint">
<jsl:jslint haltOnFailure="false" options="browser,cap,debug,devel,evil,fragment,laxbreak,on">
<formatter type="plain" />
<formatter type="xml" destfile="${root}/jslint-submodule1-out.xml" />
<fileset dir="${root}/src/main/slm.war/js/rally" includes="**/*.js" />
</jsl:jslint>
</target>
</project>
After running this against our code base, we had about 500 JSLint complaints. Once the expletives stopped and the tears dried up, I began categorizing what the issues were. In the next article I will go over what some of the common issues were, and what fixes and decisions we made regarding the different coding styles in our JavaScript.
