Back in Chapter 3, Application Structure, we touched on the build.xml file that Sencha Cmd generates as part of an application template. Now, we'll take a closer look to see how we can use this file to hook into the build process and leverage it for our own purposes.

We've already mentioned that Sencha Cmd uses Ant, an XML-based build system at its core. A key concept of Ant is that of "targets", a term that describes a bundle of tasks that perform a part of the build process from the Ant manual:

In our case, Sencha Cmd comes with a set of pre-existing targets that we can use to hook into various parts of the build process. The build.xml file contains stubs for these targets as well as some comments on what they do. We're going to hook into one of these and implement a task that will halt the build process if certain conditions are not met.

When we discussed the role of the architect, we speculated that there may be a requirement to enforce coding standards on the development team. We can use automated tools to make sure that best practice is used in a code base. Here, we'll use JSHint: a JavaScript code quality tool.

Ant is widely used and, as such, has many community-created additions. For JSHint, developer Phil Mander has created a task to use it in an Ant target. For more information, refer to https://github.com/philmander/ant-jshint.

To begin with, we need to download the Java JAR containing the new task at http://git.io/VSZvRQ.

I simply placed it in the application root along with the build.xml file, but if you've got a lot of extra tasks, it's definitely worth creating a new directory.

We can now configure our build.xml file to use this new task as follows:

<?xml version="1.0" encoding="utf-8"?>
<project name="MyApp" default=".help">

    <import file="${basedir}/.sencha/app/build-impl.xml"/>

    <!-- Expose the new task using the ant-jshint jar file -->
    <taskdef name="jshint" classname="com.philmander.jshint.JsHintAntTask" 
        classpath="${basedir}/ant-jshint-0.3.6-SNAPSHOT-deps.jar" />

    <!-- Hook into the before-init target -->
    <target name="-before-init">
        <!-- JSHint is now fully exposed via XML -->
        <jshint dir="${basedir}/app" includes="**/*.js" globals="Ext:true" options="strict=false">
            <!-- Output a report to a file called jshint.out -->
            <report type="plain" destFile="${basedir}/jshint.out" />
        </jshint>
    </target>
</project>

There are several steps to hook up this new task:

There's only one really special thing to note about the way we've configured the JSHint task and that's the need to add Ext to the globals setting. As ant-jshint hasn't been told where the Ext JS framework is, we tell it to assume that a global variable called Ext is defined elsewhere.

We can now run sencha app build again and JSHint will parse through our code and check it against its rule set. If our code doesn't pass, the whole build will fail and a file called jshint.out will be created in the root of our application and will show the details of any JSHint errors and the lines on which they occurred.

With only ten minutes work, we've already created a low-friction method of ensuring buggy or low-quality code is less likely to reach production.

This is just one example of a prebuild check. You could also:

By preventing a build from being created if these checks don't pass, you're enforcing a standard way of working across the board and forcing developers to check all of the little things that go towards creating a quality product.