Highland.js changelog

Changelog History

Page 3

• v2.10.2 Changes

  🛠 Bugfix

  • Uncaught errors from promise-back streams weren't being correctly logged in certain circumstances when using a Promise implementation that does not log unhandled promise exceptions. All uncaught highland errors should now be correctly logged. #591. Fixes #589.
  • 👀 Users using bluebird as their Promise implementation may have seen an error that says "a promise was created in a handler at ... but was not returned from it". This is a false positive, and Highland's use of promises have been updated to suppress this warning. #588.

• v2.10.1 Changes

  🛠 Bugfix

  • Asynchronously pushing a nil in consume when then input value wasn't a nil itself now no longer causes the stream to deadlock. #564. Fixes #563. Related to #558.
  • 📚 Much improved documentation. Examples are now more standalone, and more guidance was added for certain common pitfalls.

• v2.10.0 Changes

  🆕 New additions

  • of: Creates a stream that sends a single value then ends. #520.
  • fromError: Creates a stream that sends a single error then ends. #520.
  • When constructing a Highland stream from a Node Readable, the onFinish handler may now turn off the default automatic end on errors behavior by returning an object with the property continueOnError set to true. #534. Fixes #532.

• v2.9.0 Changes

  🆕 New additions

  • It is now possible to pass an custom onFinish handler when constructing a Highland Stream from a Node Readable Stream. This allows for special detection of stream completion when necessary. #505. See #490 for a discussion on why this is necessary.

• v2.8.1 Changes

  🛠 Bugfix

  • The Readable stream wrapper changes from 2.8.0 assumed that close would never be emitted before end for any stream. This is not the case for Sockets, which will close when the client disconnects but will end only when it has piped all of its data. For a slow consumer, end may happen after close, causing the Highland stream to drop all data after close is emitted.

  This release fixes the regression at the cost of restoring the old behavior of never ending the Stream when only close is emitted. This does not affect the case where error events are emitted without end. That still works fine. To manually end a stream when it emits close, listen to the event and call stream.end(). Fixes #490.

• v2.8.0 Changes

  🛠 Bugfix

  • A Highland Stream that wraps Readable now properly handles the case where the Readable emits the close event but not the end event (this can happen with an fs read stream when it encounters an error). It will also end the wrapper stream when it encounters an error (this happens when reading from a non-existent file). Before, such streams would simply never end. #479. Fixes #478.

  🆕 New additions

  • toCallback: method for returning the result of a stream to a nodejs-style callback function. #493. Fixes #484.

  👌 Improvements

  • A Highland Stream that wraps a bluebird promise can now handle bluebird cancellation. When the promise is cancelled the wrapper stream is empty. #487. Fixes #486.

• v2.7.4 Changes

  🛠 Bugfix

  • 🔀 mergeWithLimit no longer causes an // Unhandled 'error' event error when one of its sources emits an error. #476. Fixes #475.

• v2.7.3 Changes

  🛠 Bugfix

  • pipe now properly unbinds its drain handler from the destination when it is done. Previously, there would have been a memory leak if the destination is long-lived (e.g., as with process.stdout). #466.

• v2.7.2 Changes

  🛠 Bugfix

  • 📚 Minor fixes to the documentation.

  🆕 New additions

  • 💻 The library's browserify bundle is now published to NPM alongside the regular code. #310. Fixes #309.

• v2.7.1 Changes

  🛠 Bugfix

  • pipe now emits the pipe event to the destination stream. #450. Fixes #449.

  🆕 New additions

  • pipe now takes a second, optional options argument that allows users to decide whether or not to end the destination stream when the source ends. #450.

• « First
• ‹ Prev
• 1
• 2
• 3
• 4
• Next ›
• Last »