Don't inspect stream._readableState.ended

The onclose handler is coupled to node core’s stream implementation details, which creates some unfortunate problems for userland streams.

var onclose = function() {
  if (readable && !(rs && rs.ended)) return callback.call(stream, new Error('premature close'));
  if (writable && !(ws && ws.ended)) return callback.call(stream, new Error('premature close'));
};

If you have a readable stream that doesn’t have a _readableState member (or writable/_writableState), then this always raises a premature close error.

While it was straightforward to work around in my case, it was surprising and unnecessarily tricky to debug.

I suggest either of the following approaches:

1. If a stream doesn’t have a readable/writable state, don’t add the “premature close” check at all. Then the line becomes:

   if (readable && rs && !rs.ended) return callback.call(stream, new Error('premature close'));
   if (writable && ws && !ws.ended) return callback.call(stream, new Error('premature close'));
   

2. If a stream doesn’t hae a readable/writable state, throw a TypeError at the outset so that people don’t attempt to use eos with Streams that don’t derive from the core stream classes.

[isaacs]

@lovell Yeah, that broke a bunch of stuff that was already using ended to mean something different. Sometimes a semver minor change turns out to be breaking, unfortunately.

Minipass streams have an emittedEnd getter that means the same thing, anyway. Just less pretty than “ended”, imo. But also, if you add an end event handler on a Minipass stream, and it’s already ended, it’ll re-emit immediately, so it’ll be like it just ended. Kind of like how a resolved promise automatically calls the cb you pass to .then().

[isaacs]

Also, Minipass streams have destroy now.