In the general sense ... are we making this harder than it needs to be?

const results = [];
rawResponseStream
  .on('data', results.push)
  .on('end', () => {
    err.message = results.concat();
    throughStream.destroy(err);
  });
});

Adding @stephenplusplus, the stream whisperer, to chime in :)

Can this be a problem with utf-8 when ligatures will be in separate chunk from characters?

@TrySound I believe get-stream is doing essentially the example @JustinBeckwith provided, but let me know if I missed it. I think the point is, we could probably duplicate the logic in both of these modules relatively easily and avoid any extra dependencies. In either case, I would still lean towards using get-stream just for simplicity. Especially since it's already a huge win, size-wise, over concat-stream.

This might be easier to read if it was something like:

getStream
  .buffer(fileStream)
  .then(contents => callback(null, contents))
  .catch(callback)

I know you copied our existing callback.bind(null, null) (thank you for the attention to detail), but I think arrow functions are new since we wrote this, so we can "upgrade" now, if you're willing :)

Not really easier. Refinement will be invalidated and callback will become nullable again.

True, I think TS makes both options much less readable :) I think "bind" was a well-known, useful solution in the old days, but I don't know how many generations of developers are left who will see that and know what's really happening or why. And with arrow functions being an option, I don't think we have a good explanation anymore. Thanks for making the change.

I used optional chaining to simplify this. Looks like everything still works.