Problem with gulp-watch and typescript task

[floatdrop]

Problem with gulp-watch and typescript task

[floatdrop]

You should use batching mode, because gulp-tsc start compiling on end event, which is not emitted in stream mode.

[avanderhoorn]

Thanks for getting back to me. I tried the following and its sort of working but not quite (I think this is what the docs has described as batching mode):

gulp.task('watch', [ '...', 'tscompile', '...' ], function() {
    tsFiles()
        .pipe(watch(function(files) {
            return files
                .pipe(plumberDefault())
                .pipe(tscompileTask())
                .pipe(livereload(server));
        }));

// I also tried the below and it acted virtually the same 

    watch({ glob: config.app.ts, name: 'TypeScript' }, function(files) {
        return files
            .pipe(plumberDefault())
            .pipe(tscompileTask())
            .pipe(livereload(server));
    });
});

Firstly, when the watch task runs, it executes whats in the watch method as if the files have changed. This isn't really expected as I already have the tscompile as a dependent task.

Additionally, if a change that I make to the file "breaks" the watch(function() { ... }), even though I'm using plumber, it doesn't recover fully again. It just does the first part of the task again.

[floatdrop]

@avanderhoorn look at the option passThrough and emitOnGlob for fixing launching at first run.

I don't really understand, what are those tasks in gulp.task('watch', [ '...', 'tscompile', '...' ], function() {? Watch task (almost always) is main task and don't have dependencies, because they will not be re-executed when watch get file changes.

[avanderhoorn]

@floatdrop Thanks again for helping out!

Adding the emitOnGlob for the first run and I get what you mean about the watch task having dependencies. I will look into that.

Unfortunately, I'm still having issues of the watcher not working after a failed step. Here is the current log:

//Make a simple change, all works well
[08:19:33] TypeScript saw test3.ts was changed
[08:19:34] Compiling TypeScript files using tsc version 1.0.1.0
[08:19:36] test3.js was reloaded.
[08:19:36] Live reload server listening on: 35729

//Cause error on purpose, stops after the linting
[08:19:46] TypeScript saw test3.ts was changed
(quotemark) test3.ts[4, 11]: " should be '
(semicolon) test3.ts[4, 38]: missing semicolon
(whitespace) test3.ts[5, 1]: missing whitespace
[08:19:46] ERROR: gulp-tslint - Failed to lint: test3.ts.

//Tried making a valid change, but doesn't compile
[08:19:54] TypeScript saw test3.ts was changed

//Tried again making a valid change, but doesn't compile
[08:20:05] TypeScript saw test3.ts was changed

As you can see, the system is detecting that the files have changed, but isn't getting beyond that.

[floatdrop]

@avanderhoorn could you post your gulpfile as a gist?

[avanderhoorn]

Yep its here - https://gist.github.com/avanderhoorn/180a96347bc139359433

[floatdrop]

Okay. I cleared out gulpfile to contain only typescript compilation: https://gist.github.com/floatdrop/67ef2ea6c5cb291f458a

You are using lazypipe, which is appending its own onError handler, so gulp-plumber will not add another on top of existing one (see this issue), so after tscompileTask is throwing you got broken typescript building.

[avanderhoorn]

HUGE thanks for this! So at least I'm not crazy. Have to see what happens with that issue.

[floatdrop]

@avanderhoorn drop this line instead of gulp-plumber, it should fix your problem.

[avanderhoorn]

@floatdrop Not sure exactly what you mean?

[floatdrop]

@avanderhoorn I mean you can attach on('error') handler - https://gist.github.com/floatdrop/b9c7c850d3bc2e4d0a64#file-gulpfile-js-L138 and it will fix rebuilding typescript on exceptions from compiler.

[avanderhoorn]

Cool, thanks!

[avanderhoorn]

I've also found that if I remove the return this works:

    watch({ glob: config.app.ts, emitOnGlob: false, name: 'TypeScript' }, function(files) {
        files
            .pipe(plumberDefault())
            .pipe(tscompileTask())
            .pipe(livereload(lrServer));
    });