Don't add streams support?

[ronag]

One way to make things more spec compliant would be to not add support for Node streams and only AsyncIterables. That way developers that want to be cross platform compatible just have to avoid whatwg/Node streams and instead use AsyncIterable API's and it will work the same.

[Ethan-Arrowood]

I'm +1 for this if we have a goal to be cross-plat

[ronag]

@mcollina @jasnell WDYT?

[jasnell]

I would agree.

[mcollina]

I agree!

[ronag]

We should probably revive (nodejs/undici#363). In the meantime undici-fetch can always use Readable.from(iterable).

[jimmywarting]

I have just recently tried to suggest/strive away from using either node or whatwg streams in node-fetch also, will see how far it goes if it can eventually operate on only AsyncIterator instead. (this would mean treating `blob.stream() as a iterator also)

[mcollina]

I have just recently tried to suggest/strive away from using either node or whatwg streams in node-fetch also, will see how far it goes if it can eventually operate on only AsyncIterator instead. (this would mean treating `blob.stream() as a iterator also)

I think that'd be best. Have you got a link?

[jimmywarting]

Don't have a exact issue/link for it - more scattered around bit of places

• Allow ReadableStream passthrough node-fetch/node-fetch#1096 (comment) - more about the bottom half of it
• "Bring your own stream" node-fetch/node-fetch#647 - (kind of the same thing) about accepting a whatwg stream as a body input
• preparation for whatwg stream on blob.stream() node-fetch/node-fetch#1091 - maybe wanted to replace fetch-blob's stream method into a basic asyncIterator instead to have it be more cross platform independent
• Wrap blobs into a node stream node-fetch/node-fetch#1092 - starting to regret that i wrapped blob.stream() or rather "slicing-and-reading" into a node stream and didn't use a AsyncIterator directly. But that requires the bottom line of where we are sending all chunks to a http request to use iterator instead of piping
  • Maybe will try to solve that thing next

All of it is more about supporting/accepting a AsyncIterator as an input then it is about returning something that should be a stream, eg we might still want response.body to still be the same underlying http response stream - don't see any reason to downgrade it to only be a AsyncIterator when it already is a async iterator in itself.

[Ethan-Arrowood]

with #43 the api is now going to accept any AsyncIterator as a body; meaning we can support either WHATWG or Node.js stream implementation. More work to be done on the body itself but this is a great step towards spec-compat