esprima.js/gulp-strip-debug interfering with gulp-jshint task by reporting unhelpful errors when stripping debugger statements

Question

This is something that just started happening yesterday, and it's causing me a big headache.

As part of my build for arcade.ly I have a check-scripts task that strips debugging code and runs jshint over all my JavaScript:

gulp.task('check-scripts', function () {
    return gulp.src([
        'src/static/scripts/common/pinjector.js',
        'src/static/scripts/common/service.*.js',
        'src/static/scripts/asteroids-starcastle/*.js',
        'src/static/scripts/asteroids/asteroids.js',
        'src/static/scripts/asteroids/app.js',
        'src/static/scripts/starcastle/actor.*.js',
        'src/static/scripts/starcastle/service.*.js',
        'src/static/scripts/starcastle/starcastle.js',
        'src/static/scripts/starcastle/app.js',
        'src/static/scripts/space-invaders/actor.*.js',
        'src/static/scripts/space-invaders/service.*.js',
        'src/static/scripts/space-invaders/space-invaders.js',
        'src/static/scripts/space-invaders/app.js',
        'src/server/*.js',
    ])
    .pipe(stripDebug())
    .pipe(jshint({
        laxbreak: true,
        multistr: true
    }))
    .pipe(jshint.reporter('default'))
    .pipe(jshint.reporter('fail'));
});

Up until yesterday this was working absolutely fine and, if there was a problem, I'd get a helpful jshint error telling me exactly what's wrong. Now, when I run gulp check-scripts, if there's a problem I often get this kind of error:

11:47:00] Starting 'check-scripts'...

events.js:154
      throw er; // Unhandled 'error' event
      ^
Error: Line 30: Unexpected identifier
    at constructError (/Library/WebServer/Documents/arcade/node_modules/esprima/esprima.js:2406:21)
    at createError (/Library/WebServer/Documents/arcade/node_modules/esprima/esprima.js:2425:17)
    at unexpectedTokenError (/Library/WebServer/Documents/arcade/node_modules/esprima/esprima.js:2499:13)
    at throwUnexpectedToken (/Library/WebServer/Documents/arcade/node_modules/esprima/esprima.js:2504:15)
    at expect (/Library/WebServer/Documents/arcade/node_modules/esprima/esprima.js:2522:13)
    at expectCommaSeparator (/Library/WebServer/Documents/arcade/node_modules/esprima/esprima.js:2546:13)
    at parseObjectInitializer (/Library/WebServer/Documents/arcade/node_modules/esprima/esprima.js:3052:17)
    at inheritCoverGrammar (/Library/WebServer/Documents/arcade/node_modules/esprima/esprima.js:2680:18)
    at parsePrimaryExpression (/Library/WebServer/Documents/arcade/node_modules/esprima/esprima.js:3246:20)
    at inheritCoverGrammar (/Library/WebServer/Documents/arcade/node_modules/esprima/esprima.js:2680:18)

As you can see, there's no useful information in there. At the moment I'm refactoring so my changesets often cover a number of files. The issue here is I can see esprima's parser is unhappy but I have no idea which file is breaking it, nor which line of code within that file.

I can figure it out by iteratively commenting and uncommenting lines in check-scripts and rerunning gulp-checkscripts, and eventually by commenting and uncommenting code, but it's obviously a bit of a chore.

In this case this is the code that caused the error:

function masterSoundConfiguration() {
    var masterConfig = {
        elementCountForRapidRepeat: 6,
        sfxMasterVolume: 0.4,
        musicMasterVolume: 0.6,
        sounds: [],
        music: []                        // <-- Missing comma
        mergeIntoMaster: mergeIntoMaster
    };

    ...
}

As you can see, there's a missing comma, which is causing the error.

The problem seems to be caused by gulp-strip-debug, but if I simply disable this jshint will complain because of debugger statements. Since I need to build to run the site even in dev, this is a hassle.

I suppose I could disable gulp-strip-debug and configure jshint to ignore debugger statements, for dev builds only, but is there a way to configure gulp-strip-debug to report errors better, or is this a bug/design flaw/oversight?

Any insight/suggestions would be gratefully received.

Thanks,

Bart

Answer 1

The gulp-strip-debug library is a very thin wrapper around strip-debug so I'm tempted to conclude this is a bug (or deficiency) in strip-debug, although it might also be in the way gulp-strip-debug reports errors from strip-debug.

I need to investigate a little further and possibly put in a PR. It would certainly be easy enough to get it to report which file the error is in, even without the line number, which would be a big improvement in itself.