Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stream does not emit finish #245

Closed
jseanxu opened this issue Dec 4, 2015 · 10 comments
Labels
Bug

Comments

@jseanxu
Copy link

@jseanxu jseanxu commented Dec 4, 2015

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 ivogabe added the Bug label Dec 6, 2015
@ivogabe

This comment has been minimized.

Copy link
Owner

@ivogabe ivogabe commented Dec 6, 2015

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 comment has been minimized.

Copy link

@LPGhatguy LPGhatguy commented Dec 16, 2015

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

This comment has been minimized.

Copy link
Owner

@ivogabe ivogabe commented Dec 16, 2015

@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

This comment has been minimized.

Copy link
Author

@jseanxu jseanxu commented Jan 19, 2016

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

@ivogabe ivogabe closed this in 136a350 Jan 22, 2016
@ivogabe

This comment has been minimized.

Copy link
Owner

@ivogabe ivogabe commented Jan 22, 2016

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

@laurelnaiad

This comment has been minimized.

Copy link

@laurelnaiad laurelnaiad commented Jan 24, 2016

(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

This comment has been minimized.

Copy link
Owner

@ivogabe ivogabe commented Jan 25, 2016

@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

This comment has been minimized.

Copy link

@laurelnaiad laurelnaiad commented Jan 25, 2016

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

This comment has been minimized.

Copy link
Owner

@ivogabe ivogabe commented Feb 2, 2016

@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

This comment has been minimized.

Copy link

@laurelnaiad laurelnaiad commented Feb 2, 2016

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. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.