However if instead of processing the chunks manually you wanted to pipe to another stream, then you'd be attaching the on('done') listener to the target stream:
needle
.post('https://my.server.com/foo', data, { multipart: true })
.pipe(someWritableStream)
.on('done', function(err) {
// this would never fire, because it's Needle's response
// that emits the 'done' event, not the writableStream returned by the pipe() function
})
This PR ensures that both Needle's response and its target streams, when piped, all emit the 'done' event, providing a more consistent way of piping streams.
On a related note, please take a look at #372 for more info regarding error handling on streams. The gist of it is that you should use stream.pipeline instead of pipe, when possible.
This lets us use a consistent API regardless listening to events on the response stream itself or to destination/writable streams.
This is one of the examples in the readme:
However if instead of processing the chunks manually you wanted to pipe to another stream, then you'd be attaching the
on('done')
listener to the target stream:This PR ensures that both Needle's response and its target streams, when piped, all emit the 'done' event, providing a more consistent way of piping streams.
On a related note, please take a look at #372 for more info regarding error handling on streams. The gist of it is that you should use
stream.pipeline
instead ofpipe
, when possible.