Linting your code

You could execute gulp emulate --platform ios (or android) right now; the app should work. But how do we know whether our code will work when it is built? Better yet—how can we prevent a build if the code isn't valid?

We do this by adding lint tasks to our Gulp configuration. Linting is a lot like compiling; the linter checks your code for obvious errors and aborts if it finds any. There are various linters available (some better than others), but not all of them support ES2015 syntax yet. The best one that does is ESLint (http://www.eslint.org). Thankfully, there's a very simple Gulp plugin that uses it.

We could stop at linting and be done, but code style is also important, and can catch out potentially serious issues as well. As such, we're also going to be using the JavaScript Code Style checker or JSCS (https://github.com/jscs-dev/node-jscs).

Let's create tasks to lint and check our coding style. First, we need to add some additional configuration to gulp/config.js:

var config = { …,
    lint: "src/www/js/app/**/*.js",
    "code-style": "src/www/js/app/**/*.js"
}

Now, let's create the associated tasks. Let's start with linting—this will live in the gulp/tasks/link.js file:

var gulp = require("gulp"),
    eslint = require("gulp-eslint"),
    config = require ("../config"),
    settings = require("../settings"),
    paths = require("../utils/paths");
function lintCode() {
    return gulp.src(paths.makeFullPath(config.lint))
        .pipe(eslint(paths.makeFullPath("eslint.json", 
          paths.CONFIG)))
        .pipe(eslint.format());
}
module.exports = {
    task: lintCode
}

The task for checking our code style will be named gulp/tasks/code-style.js. It should have the following code:

var gulp = require("gulp"),
    jscs = require("gulp-jscs"),
    config = require ("../config"),
    settings = require("../settings"),
    paths = require("../utils/paths");
function checkCodeStyle() {
    return gulp.src(paths.makeFullPath(config["code-style"]))
        .pipe(jscs({
            configPath: paths.makeFullPath("jscs.json", 
                          paths.CONFIG),
            esnext: true
        }))
        .pipe(jscs.reporter())
        .pipe(jscs.reporter('fail'));
}
module.exports = {
    task: checkCodeStyle
}

Now, before you run either task, you'll need two configuration files to tell each task what should be an error and what shouldn't be. We suggest using the files from the code bundle for this chapter for now (you can find them in the logology-v01/config directory). If you want to change the settings, you can do so; the sites for ESLint and JSCS both have information on how to modify the configuration files.

Tip

config/eslint.json must contain "parser": "babel-eslint" in order to force it to use the ES2015 syntax. This is set for JSCS in the Gulp configuration, however.

config/jscs.json must exist and must not be empty. If you don't need to specify any rules, use an empty JSON object ({}).

Now, if you were to execute gulp lint and our source code had a syntax error, you would receive an error message. The same goes for code styles; gulp code-style would generate an error if it didn't like the look of the code.

Next, you should add these two tasks to our build, emulate, and run tasks. Here's what the module.exports of gulp/tasks/build.js looks like after doing this:

module.exports = {
    deps: ["copy", "lint", "code-style"],
    task: …
}

Now, if you execute gulp build and there is a linting or code style error, the build will fail with an error. This gives a little more assurance that our code is at least syntactically valid prior to distributing or running the code.

Note

Linting and style checks do not guarantee that your code works logically. It just ensures that there are no syntax or style errors. If your program responds incorrectly to a gesture or processes some data incorrectly, a linter won't necessarily catch these issues.