feat: implement EventSource

[Uzlopak]

This PR is not author-ready.
I wanted to propose to add EventSource as native module. This is working in a reasonable way and I personally like the overall structure of the implementation.
Still has to be made full spec compliant and hardened. Also needs the use of primordials and the EventSourceStream-class is not handling EOL characters properly, which needs to be implemented properly.

But before I invest more, I wanted to discuss two aspects of this implementation, which need clarification as they popped up while implementing.

1. EventSource in a Browser UserAgent expects that you can use "withCredentials" option to send cookies with the request. So this is kind of limiting as I assume that node native fetch is not storing any cookies. So maybe we should deviate from the spec and allow maybe like npm:eventsource to pass headers via the options parameter. Thus you could also use the authorization header to connect to a EventSource server.change
2. Do we actually want to integrate EventSource to nodejs? deno implemented it, but should we do it too?

Anyhow, I worked on it for few days an now I want to clarify with you, if this feature is even desired. Not that I finish the nicest EventSource implementation, but it has no chance to get integrated into node core.

Looking forward to your feedback regarding my questions. If there is positive feedback then I am glad to finish the code ;).

[nodejs-github-bot]

Review requested:

• @nodejs/startup
• @nodejs/web-standards

[mcollina]

My 2 cents is that this is better implemented as part of Undici.

[Uzlopak]

@mcollina

I would be glad, if we integrate this first into undici and then expose it to node core via integrated undici.

[Uzlopak]

@mcollina

I have the problem, that NodeEventTarget is not exposed. I can get kEvents Symbol indirectly. But NodeEventTarget is not possible to load from userland.

I could duplicate the code of NodeEventTarget for an undici implementation, but this doesnt seem right.

[targos]

You can get it with Object.getPrototypeOf(MessagePort) for example, but why do you need it? Shouldn't EventSource extend from EventTarget directly? We don't need the compatibility layer of NodeEventTarget in new APIs unless I'm missing something.

[Uzlopak]

EventTarget is missing e.g. removeAllListeners, which is quite handy to manage the onmessage, onerror and onopen attributes.

kEvents of EventTarget can be retrieved by doing

const kEvents = Object.getOwnPropertySymbols(new EventTarget())
  .find((symbol) => {
    return symbol.description === 'kEvents'
  })

But I guess, on second thought, I can do it with kEvents to access the Map. But it is not that nice tbh.

[mcollina]

Ok for it to stay here.

[KhafraDev]

This is better in undici, I agree with @mcollina. We already implement MessageEvent and obviously fetch. Managing the events is quite easy and we do it without NodeEventTarget.

[Uzlopak]

I will have a look at it tonight (well it is already night) ;). I actually like it also to be in undici, as it opens my hands for a better structuring of the files instead of putting everything into a single event_stream.js. ;).

I will keep you updated.

[KhafraDev]

I'm willing to help if you have any questions.

[Uzlopak]

Closing in favor of nodejs/undici#2608

See you over there :D