make global object an instance of `EventTarget`

[jimmywarting]

What is the problem this feature will solve?

This sounds like a simple feature request. We already got EventTarget and Event. So my feature request is to have a globalThis.addEventListener. (along with remove & dispatch) added to the global scope (by extending EventTarget)

What is the feature you are proposing to solve the problem?

Deno, browser and web workers and even cloudflare workers already has a global event listener that can be used to listen to a variety of things.
It can be used for listening to eg PostMessage, network offline/online, background fetch, any kind of errors etc.

This is partly related to #43583
Having different code paths to solve the same things gets troublesome.

What alternatives have you considered?

No response

[aduh95]

I think your actual request is "make the global object an instance of EventTarget", but Node.js global object doesn't have any event attached to it (so far).

It can be used for listening to eg PostMessage, network offline/online, background fetch, any kind of errors etc.

I think I would need to have a more detailed proposal, but as is it seems... weird to attach those to the global object rather than more specialized objects.

[jimmywarting]

I think your actual request is "make the global object an instance of EventTarget

Hmm, yea... will update the title

[KhafraDev]

There's a few issues with the current EventTarget implementation that would need to be fixed:

• Use globalThis as the this value if this is null or undefined (https://webidl.spec.whatwg.org/#dfn-create-operation-function). This is only needed for EventTarget because globalThis will implement its methods/properties (ie. addEventListener(...) will work).
• Remove private properties and replace with symbols edit: EventTarget doesn't use private properties - Event does.
• Add those symbols to globalThis (easily done with initEventTarget.
• Object.setPrototypeOf(globalThis, EventTarget.prototype)

[jcbhmr]

I notice that there's some discussion in #45993 about whether or not this is a good idea. I'd like to present a particular use case for this feature: polyfills of other web platform features!

For instance, take the Worker class from the HTML spec. It uses a WorkerGlobalScope on the "inside" of the spawned worker which is an EventTarget. Current polyfills like developit/web-worker (~320k downloads weekly) need to do some song and dance to apply .addEventListener() and friends to the global scope:

    let proto = Object.getPrototypeOf(global);
    delete proto.constructor;
    Object.defineProperties(WorkerGlobalScope.prototype, proto);
    proto = Object.setPrototypeOf(global, new WorkerGlobalScope());
    ['postMessage', 'addEventListener', 'removeEventListener', 'dispatchEvent'].forEach(fn => {
        proto[fn] = proto[fn].bind(global);
    });

https://github.com/developit/web-worker/blob/29fef9775702c91887d3d8733e595edf1a188f31/node.js#L167-L173C5
ref https://html.spec.whatwg.org/multipage/workers.html#the-workerglobalscope-common-interface

There are other polyfills that target other browser-related APIs that would benefit from the common baseline of assuming that the globalThis is an instance of EventTarget. For instance, polyfills for the unload (process.on(exit)) beforeunload (process.on(beforeExit)) etc. would all need to do this song and dance, but will do it in a slightly different way that may-or-may-not be if-gated and override or stack EventTarget.prototype shims on top of each other! 😩

Having this EventTarget globalThis be in Node.js core would be beneficial to avoid clashing shims. I think it would also be a good step towards #43583. If a Node.js-native Worker ever happens, having globalThis already be an EventTarget would mean less "inside the Worker is an EventTarget, but the normal Node.js global is NOT an EventTarget" mayhem and mismaps.

[jimmywarting]

miniflare is another popular user package with (~250k downloads / week) that emulates a spec'ed worker by having global fetch event listener.

And it's evidents by all ~250 👍 on the 2nd most upvoted NodeJS feature request 👉 #43583 that ppl want to have a isomorphic way to create web worker that can listen to standard classic message events in the same way.

because it's such a pain to deal with the differences of worker_threads and Web Worker API

the fact that worker_threads is different enough from Worker often makes me decide just not to bother with threads at all in code (even though it could often benefit) that is polymorphic for Node/Browsers

NodeJS is the only one going against the flow.

I too also wish to be able to register a unload event instead of having to depend on process.on('exit') (i don't wish to bring in the hole process package into other runtimes only for using it globally or importing it from node:process

[benjamingr]

I think having globalThis extend EventTarget and making our workers also web workers (assuming there is no performance penalty) is a much less controversial ask than making the Node global an EventTraget.

[KhafraDev]

Node's global and globalThis are equal to each other, we can't do it to only 1 of them. My PR made globalThis extend EventTarget, similar to other environments. Web workers were brought up in my PR, the general gist being that until someone wishes to implement web workers, my PR would be blocked.

[jimmywarting]

the general gist being that until someone wishes to implement web workers, my PR would be blocked.

That was half of the reason why i made this feature request.
To implement cross comp. worker we would need to have onmessage or addEventListener as global

we can't have web compatible workers if we don't have a EventTarget on globalThis hence why it would be blocked on @KhafraDev PR

[jimmywarting]

If this ever get resolved then i would like for some other things to be considered but they are blocked by this particular issue.

• Make globalThis extend EventTarget
  • When receiving post messages in a worker, construct a MessageEvent and dispatch it to globalThis
  • Add globalThis.postMessage that can reply back without having to including parentPort from worker_thread
  • Add globalThis.onmessage as an alternative mean to using addEventListener
    • maybe flag worker_thread.parentPort as a bit obsolete (just doc wise)
  • implement some of Deno's events
    • load
    • beforeunload
    • unload
    • unhandledrejection
  • Support Web Workers #43583
  • Cross-thread URL.createObjectURL  #46557 to better be able to create dynamic worker / ESM code:
    • Being able to do import(blobUrls) #47573
    • being able to do new Worker(blobUrl)
    • allow "experimental loaders" to fetch the content out of blob urls (no matter where the thread came from)
    • basically allow any thread to just fetch(blobUrl) where a blob could come from another thread
  • Make disk- blob transferable #47666