• issue 75: Handle BOMs when using the CLI.
• issue 74: Document the technique for construction of JSLint objects.
• issue 73: Better examples for maven configuration.
• issue 72 : Add all formatters to the maven plugin automatically.
• issue 67 : Fix maven docs.
• Update to JSLint 2012-02-03.
  • This removes the adsafe, confusion and safe options.
  • This adds the anon option.

One minor point: Now that google code supports git repositories, I’m also pushing the source code there again. Github is still my “primary” but there’s another copy. More copies are good.

I did spend a bit of time testing the CLI interface properly. This isn’t really noteworthy, but it was entertaining for me, and hopefully results in fewer bugs like issue 75.

There is also a breaking change, that’s been inherited from JSLint. The meaning of several options has been inverted. Now, the default is to behave strictly, with options turned off. For example, if you want to turn off JSLint’s checking of whitespace, you now have to specify --white. Previously, this would enable checking of whitespace. See the release notes for details, and please take care when updating.

The maven plugin should behave much like any other maven plugin: you add it to your <build><plugins> section. Here’s an example:

<plugin>
  <groupId>com.googlecode.jslint4java</groupId>
  <artifactId>jslint4java-maven-plugin</artifactId>
  <version>2.0.0</version>
  <executions>
    <execution>
      <id>lint</id>
      <phase>process-resources</phase>
      <goals>
        <goal>lint</goal>
      </goals>
      <configuration>
        <failOnError>true</failOnError>
        <options>
          <undef>true</undef>
        </options>
      </configuration>
    </execution>
  </executions>
</plugin>

I’d love feedback on how well this works.

What’s new?

• Added OSGI bundle headers.
  • I’m an OSGI novice; please let me know if these are wrong.
• issue 52: Add checkstyle xml formatter.
• issue 53: No files passed to the ant task is no longer an error (just an info message).
• Update to JSLint 2011-03-07.
  • This adds the continue option, whilst removing eqeqeq, immed and laxbreak options.
  • JSLints interpretation of line and column numbers has changed. I’ve tried to keep up. Please file a bug if errors aren’t reported at the expected place.

What’s really interesting has been paying attention to the integrations that people have come up with. It’s never been easier to have lint-free JavaScript!

Sonar

If you use the sonar code quality tool, check out the javascript-plugin-for-sonar which uses jslint4java.

HudsonJenkins

The hudson violations plugin can display JSLint errors in your project. You still have to arrange to run jslint4java as part of your build though.

Emacs

Want to run JSLint inside Emacs? Have a look at this gist.

Gradle

Do you use gradle for your builds? kellyrob99 has produced a gradle-jslint-plugin.

Mercurial

Want to run JSLint automatically when using mercurial? Take a look at Running JSLint as Mercurial precommit hook.

Netbeans

Check out Integrating JSLint more tightly into NetBeans.

Maven

Whilst there’s a jslint4java maven plugin in the works, this stackoverflow post describes several ways of integrating JSLint with Maven.

Phonegap

If you’re doing Phonegap development, the latest version of the eclipse plugin comes with JSLint.

If you develop an open source project, then you really should set up a google alert for its name. You will be surprised.

What’s coming up?

• Update to the latest JSLint (as always). Doug Crockford recently did a major rewrite. I think I’ve got that mostly integrated now, but not released.
• There are a few outstanding bugs that I need to pay attention to.
• I’ve also been working on my own jslint4java-eclipse plugin, which feels nearly complete enough to release.
• Assuming I can ever figure out the integration testing, I’ll go back and finish off the jslint4java-maven-plugin.

Plenty to keep busy with!

•  issue 35 : Removed embedded JUnit.
•  issue 30 : Add a "report" formatter to the ant task.
  • Also available on the command line with --report
•  issue 37 : add a --encoding flag for specifying the encoding files on the command line.
•  issue 36 : add a JUnit XML formatter.
•  issue 26 : add support for .data() call in JSLINT.
  • This is only available in the Java API right now.
•  issue 39 : add failureproperty to the ant task.
• Use JCommander for flag processing.
  • (INCOMPATIBILITY) This means that command line option parsing has changed slightly. You now have to say --indent 2 instead of --indent=2.
  • (INCOMPATIBILITY) The minimum version of Java is now 6.
• Update to JSLint 2010-07-14.
  • Adds options: es5, windows.
  • Removes options: sidebar.

I’m really grateful to Cédric Beust for JCommander. It’s a really nice little library.

• Support for the predef option, so you can specify a list of predefined global variables. I first said I’d do this over a year ago.
• Updated to JSLint 2009-11-24, which brings a new devel option. Now you can decide if alert(), console.log(), etc are available.

Unfortunately, just after I’d committed the release, I noticed that I’ve managed to (somehow) pick up a junit dependency. I’ll set about removing that for the next release (issue 35).

This release also upgrades to JSLint 2009-10-04, which sports a new maxerrs option.

Apart from that, I’m particularly grateful to both Simon Kenyon Shepard and Ryan Alberts for pointing out where my unit tests where non-portable. I really need to get hudson up and running on the games PC…

Nonetheless, it’s kind of useful to be able to look at a version of JSLint and say “this changed since the last version”. So, I’ve started mirroring www.jslint.com into a git repository. I check for updates every hour.

This means you can now see how JSLint changes over time.

Now, it’s not as useful as it could be. It would be nice to tie these up to the changes that Douglas posts to the mailing list (e.g. announcing the new .data() support). But that’s quite a bit more work.

I hope that this is beneficial to somebody.

¹ It’s amazing how normal public version control has become over the years. This used to be a lot less common, which made projects a lot harder to understand.

But it really feels like it starts to fall apart when you get to a multimodule build. Maven does quite a few nice things for you, but you start to see some annoying glitches here. One of the first ones I came across was the url element. If you set it correctly in the root pom (e.g. http://mycompany.com/project/) then maven automatically appends the artifactId when constructing the site for submodules. So you end up with http://mycompany.com/project/mysubmodule/, which isn’t necessarily correct.

After thinking about this for a while, and how best to document jslint4java, I’ve come to the same realisation as Mark Pilgrim: plain old HTML works best. I’ve tried a few like Textile (yuck), Markdown (better), POD (too simple) and docbook (too complex). HTML strikes the right balance. Especially with the new HTML5 tags. And it doesn’t require any building to view it. Just hit refresh.

So how to make it part of the maven build? Easy. Stuff it into it’s own submodule. Then, it can be referenced by the assembly plugin later and put in the correct place in your distribution. Check out jslint4java-docs for details. It would be nice if maven natively supported zip packaging, but that’s easily overcome.

This does mean it doesn’t get automatically deployed to a server. But that doesn’t really matter. It happens infrequently enough that I’m happy to do that by hand where needed. Or at least find a better solution when I get bored of that.