Consider returning undefined instead of a stream

[phated]

I found it very counter-intuitive that this module returns a stream but it doesn't propagate errors to it. Would you consider not returning the produced stream?

[yoshuawuyts]

+0 on this; I agree with you it's the more intuitive solution, but pump is widely used and API stability counts for something - so perhaps better docs is the best resolution?

[phated]

@yoshuawuyts if you are using the returned stream from pump, you most likely want to be using pumpify instead of pump, right?

[mafintosh]

fyi, it returns the last stream to be api-compatible with .pipe - i agree the docs could be clearer on this.

[phated]

To elaborate on this a bit more: We were planning to recommend pump for writing gulpfiles, but gulp handles people returning streams by listening for error and end events with end-of-stream; however, this module swallows the errors but still looks/acts like a stream in other ways. It seems like a footgun for people if they use implicit returns from arrow functions and no callback with pump (this happened with a gulpfile in the lodash org).

[phated]

cc @jdalton

[mafintosh]

i don't feel strongly about this. we can do a major bump and not return the last stream if it is a big issue. feel free to pr that.

[phated]

@mafintosh cool, I'll do it in a few days to leave this open for a bit to get more feedback

[qfox]

Isn't it be more intuitive to use pump just in pipe calls? Not sure it's understandable as it can be:

pump(
  gulp.src('./*.files'),
  transform1(),
  transform2(),
  gulp.dest('./'),
  (err) => (err && console.error(err))
);