Stream does not emit finish

[jseanxu]

The stream does not emit a "finish" event.

My scenario is that I listen to the "error" event and proceed differently after the TS compilation depending on if there were errors present. Without the "finish" event I am forced to manually pull out the data and unable to write something like

var error = false;
ts({
        noEmitOnError: true,
        noImplicitAny: true,
        sortOutput: true,
        suppressImplicitAnyIndexErrors: true,
        target: "ES6",
      }))
 .once("error", function () { error = true; })
 .once("finish", function () { console.log(error ? "yay" : "nay") }));

[ivogabe]

Did a quick check, and the finish event is indeed not emitted. You can use the end event until this is fixed. (Maybe the end event is actually better in this case, but I'm not sure about that.)

[LPGhatguy]

This might be causing a problem with gulp-typescript and gulp-watch: the combination causes the stream to never resolve, presumably due to a missing 'finish' event?

return gulp.src("server/**/*.ts")
    .pipe(watch("server/**/*.ts"))
    .pipe(gulpTypescript(tsConf))
    .pipe(gulp.dest("debug"));

[ivogabe]

@LPGhatguy gulp-watch returns an endless stream. gulp-typescript needs to have all files so waits for the end of gulp-watch. Because of that, you can't use these together, also not when this issue is resolved.

[jseanxu]

"end" doesn't appear to be emitted either.

[ivogabe]

@jseanxu I cannot reproduce that, can you give more details?

[laurelnaiad]

(re gulp-watch: there are ways to have an end event under gulp-watch, you just have to take action to trigger it... gulp-batch, for instance, will give you a stream that flushes after a debounce timeout... so one can certainly use gulp-watch with gulp-typescript, but you just have to trigger end on way or the other)

[ivogabe]

@laurelnaiad The compiler doesn't have all files, thus it cannot do correct type checking in such case. If you don't need type checking, you can use isolatedModules, which can already be used with gulp-watch.

[laurelnaiad]

Whoops -- forgot to mention that part! :)

I don't use isolatedModules, because I do very much want type checking. What I do is track files that were touched using gulp-watch, then replace the stream content with the results of tsproject.src(), then after ts transpilation, filter back down to only those .js and .d.ts files that correspond to files that were touched (i.e. those that came out of gulp-watch/gulp-batch). This allows the rest of my process (the next stream after this business is gulp-babel, for instance) not to be "fooled" into thinking that the entire set of files has been modified, thus restoring the incremental gulp-watch-based processing while also feeding gulp-typescript all the files it needs.

[ivogabe]

@laurelnaiad That sounds like a complex setup. I'd suggest to use something like gulp-changed instead, which you can use after gulp-typescript. That would make the setup a lot easier.

[laurelnaiad]

I'm past the point of easy. I have 6 typescript projects being built in this repo. There's quite a bit of branching in the streams of my build cycle, which are pretty well aware of why they're doing what they're doing with each file. gulp-changed wouldn't really add anything for me. For what I described above, the whole business is self-contained in a plugin, so that each of my projects can be built through it. I wouldn't have bothered, but for the benefit of being able to easily and performantly/incrementally transpile through ts and babel across lots of projects. :)