stage 3 tracking

[michaelficarra]

• all open PRs merged or rejected
• all open issues addressed or closed
• spec text finalised
• reviewer sign-off
  • Richard Gibson (@gibson042)
  • Jordan Harband (@ljharb)
  • Ron Buckton (@rbuckton)
• editor sign-off
  • Kevin Gibbons (@bakkot)
  • Shu-yu Guo (@syg)
• presentation to committee prepared

[michaelficarra]

Things have gotten really busy for me and I don't think I'll be able to prepare this for stage 3 (at least not on my own) in time for the stage advancement deadline on 10th Sep.

[Jack-Works]

Maybe also wait for tc39/ecma262#2045 to merge

[jorendorff]

I think @avandolder is interested in helping. I can help too.

The fact that tc39/ecma262#2045 is stalled is a major obstacle. If there's anything I can do to help there, let me know! You can ping me on IRC any time.

[Jack-Works]

Hmm cause there's nothing to update with #2045... I didn't get a clue about what should I change to make it merged, or it just waiting for some editor to press the merge button?

[bakkot]

The editors need to review it, which will take a while because it's a substantial change.

[michaelficarra]

@jorendorff That PR is on the top of my list for review. I'll hopefully get to it this week, possibly even today. An additional review from you (even if it just results in an approval) would be helpful.

[mpcsh]

I'm not sure how I missed this, but I will unfortunately not be able to provide the stage 3 review I committed to at the previous plenary. my sincere apologies to the champions and stakeholders. I will be doubly careful to ensure I stay on top of review commitments going forward.

[michaelficarra]

@mpcsh That's fine, we will ask for a new one at the meeting next week: tc39/agendas@868028c

[michaelficarra]

Update: @codehag has volunteered (possibly to be replaced in the future by @jorendorff).

[benjamingr]

Hey - are there any updates on this proposal? When do you expect to present it again?

(I am asking because Node.js has started to integrate async iterators in many places and this would be very useful for Node!)

[karlhorky]

@benjamingr out of interest, can you link to an example or two of how Node is using iterators in the codebase?

Also eagerly awaiting this proposal!

[benjamingr]

@karlhorky

• Every stream is async iterable (so you can for await (const chunk of createReadStream('file')), and http requests are async iterable).
• Events are async iterable with on (on(emitter, 'foo') returns an async iterable).
• Intervals are async iterable (soon).
• File system watchers are async iterable soon

But mostly streams and all stream helpers (like pipeline), the easiest way to get a Node.js stream is to use Readable.from with an async generator.

The "new way" of writing Node.js is getting rather pervasive:

• Using promises for APIs (like fs/promises).
• Using async iterators for anything that can be async iterable.
• Using AbortController for cancellation in all APIs.

I came here because I really wanted a setInterval(1000).map(someFn) and we had a discussion about this.

[benjamingr]

And to clarify - I think it's safe to say Node.js is very interested in this proposal and since a bunch of our use cases arose from web platform APIs I am sure a very compelling case can be made for it in browsers too.