The new pipeline operator in Node.js stream is borne from the experience that Mathias Buus had with pump , and it enables you to safely pipe together a list of streams, creating a pipeline. This method’s key part is safety, as it ensures every stream that is part of the pipeline will be destroyed ( stream.destroy() is called) if an error occurs or the pipeline ends prematurely. pipeline ensures that no internal resources are leaked, and we encourage all developers to use it instead of pipe.
Note that pipeline supports utils.promisify , and it could be awaited upon in that manner.
One of the oldest problem in streams is knowing if it has ended, and it was solved in the userland module end-of-stream . Multiple streams implementations and different authors have made it very hard to detect if a stream has finished reading or writing and we can stop listening for events. This utility is so critical for the usage of streams that we have added it in Node.js core, and it will be available in readable-stream as well.
Note that finished supports utils.promisify , and it could be awaited upon in that manner.
For Await (Let Chunk of Readable)
Readable now is async iterable. You can process data from a stream just using a nice for loop, as follows:
Note that the above pipeline supports backpressure, and it handles error events. AsyncIterators are currently experimental, as it’s a relatively new feature in the language being part of ES2018.
stream.push() always call _read()asynchronously
This breaking change simplifies some logic for implementers, making sure that a single _read() call is happening at any given time. In readable-stream@2 and Node.js < 10, up to two _read calls could happen at the same time, making implementing streams very complicated.
Before Node 10, the following would be an error with “Error: stream.push() after EOF“:
Can you spot why this is going to cause an error? In readable-stream@2 (and Node < 10), this.push(count++) would call _read() synchronously, causing the callback passed to setImmediate to be called one more time after we pushed null . Fixing these types of problems is hard, because they imply a good knowledge of the stream machinery. Good news, with readable-stream@3 we don’t have to worry about this problem anymore.
readable-stream now supports the same error codes that Node.js core provides, in the namespace of ERR_STREAM_* . For more details, see https://nodejs.org/api/errors.html.
Clear Browser Support Commitment
readable-stream @3 commits to support all evergreen browsers (Google Chrome, Opera, Firefox, Edge), plus Internet Explorer 11 and the latest version of Safari. We ensure that all our tests pass thanks to Sauce Labs , that provides us their service for free under their Open Sauce offering. We also use the formidable https://www.npmjs.com/package/airtap , which enables us to run our tape tests in the various browsers.