stream: implement ReadableStream.from

[debadree25]

Implements ReadableStream.from

Updating the WPTs add a lot of new tests, and failures that weren't relevant to this PR, I have added them to expected failures.

Please do take a look at the node errors used, I have used ERR_INVALID_STATE.TypeError in all the places since all the webstreams code seems to be reliant on that.

Fixes: #48389

[debadree25]

cc @nodejs/whatwg-stream

[debadree25]

Also, would this need node tests too? or WPTs are enough?

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/52169/

[mcollina]

lgtm

[benjamingr]

Can't this be an async function which would allow the catch to not exist nd the below return PromiseResolve() to just be a return etc?

[debadree25]

Hmm i think it could, let me make it so and see if the WPTs pass

[debadree25]

Hey! updated this, the WPTs don't complain and reading the spec i doesn't seem to say anything about the function having to sync or async

[MattiasBuelens]

Indeed, this is equivalent. I wanted the error handling to be very explicit in the reference implementation, but practical implementations can be more succinct. 🙂

[benjamingr]

Mostly LGTM (esp for a first version).

A few notes:

• We can simplify this a bit with async functions
• We should short circuit if we get a Node stream and use toWeb machinary if the spec allows

[debadree25]

We should short circuit if we get a Node stream and use toWeb machinary if the spec allows

where to check for this? should make a issue on the spec repo? maybe @MattiasBuelens can help?

[debadree25]

have addressed all the comments and will wait for some time if we would like to add .toWeb functionality like @benjamingr suggested

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/52185/

[MattiasBuelens]

We should short circuit if we get a Node stream and use toWeb machinary if the spec allows

where to check for this? should make a issue on the spec repo? maybe @MattiasBuelens can help?

I would recommend something like:

// at the top-level
// ideally, this is exported by `lib/internal/streams/readable.js`
const originalReadableAsyncIterator = Readable.prototype[Symbol.asyncIterator];

// in readableStreamFromIterable
if (iterable instanceof Readable && iterable[Symbol.asyncIterator] === originalReadableAsyncIterator) {
 return Readable.toWeb(iterable);
}

This way, you can be certain that you're dealing with an unmodified Readable, and that there will be no behavioral differences compared to "going the long way" using Readable's async iterator.

I also suggest you write additional tests with polluted Readable instances, or with a polluted Readable.prototype. 😉

[debadree25]

Hey one thing is it ok to export things from lib/internal/streams/readable.js something like originalReadableAsyncIterator as suggested? i know there is little bit restrictions in what we can export import in around the readable node stream part since its used in readablestream @benjamingr @mcollina

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/52751/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/52752/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/52753/

[debadree25]

Hello everyone! I have reverted the change of toWeb for now (I shall do it in a follow up, since i was getting confused 😅) PTAL it seems ready to land!

[nodejs-github-bot]

Landed in b361ad7