Extending the build system - integrating JSLLint

Javascript errors are annoying and notoriously hard to track down due to limited IDE support and misleading error messages in browsers, but often it’s only a missing comma or a bracket in the wrong place. A linter helps by checking that your javascript is a least structurally sound. It’s the first check I run on any javascript that does not work, so having it right at my fingertips is important. I’ll show how to integrate that into any agavi project.

There’s a number of JS-Linters out there, I use http://www.javascriptlint.com/, primarily because there’s an existing phing task for it (1). As the agavi build system is based on phing integrating that task is a breeze. Each agavi project has a build.xml in the root directory that can be used to define project-specific targets. By default it’s empty and looks like this:

<?xml version="1.0" encoding="utf-8"?>
<project name="Sample" basedir="." default="status">

    <!--
      Define project-specific or custom build targets.
      -->

</project>

Adding a JSL-Task is a matter of seconds:

<?xml version="1.0" encoding="utf-8"?>
<project name="Sample" basedir="." default="status">

    <!--
      Define project-specific or custom build targets.
      -->

    <target name="lint-javascripts" description="check all javascripts for validity">
        <property name="javascript.lint.showWarnings" value="true" />
        <jsllint showWarnings="${javascript.lint.showWarnings}" haltOnFailure="true">
            <fileset dir="${project.directory}/pub/">
                <include name="**/*.js" />
            </fileset>
        </jsllint>
    </target>

</project>

And now it’s just a call to

Zodiacal-Light:~ fgilcher$ agavi lint-javascripts

That’s it. It’s trivial to extend the task-definition to pass some options to the linter - I’ll leave that to you.

(1) There’s a minor bug in the JSL-Lint Task that’s fixed on trunk. See http://phing.info/trac/ticket/349