dom-exception.ts

[jimmywarting]

I thought instead of using a own custom DOMexception class, how about using this npm package instead?

[MattiasBuelens]

That package appears to be Node-specific (relying on worker_threads), whereas this polyfill targets both browsers and Node. 😕

That said, this polyfill will try to use globalThis.DOMException if it exists, so if you load node-domexception before loading web-streams-polyfill it should "just work". Yes, you'd still have an unused DOMException polyfill as part of web-streams-polyfill, but I guess there's always gonna be some dead code if you try to support multiple platforms. 🤷‍♂️

Maybe one day we can do a breaking change where the polyfill requires a global DOMException to exist, similar to how we currently require a global Promise constructor. But that'd require Node 17 or higher, and it'll probably be a couple of years before we can safely drop support for Node < 17...

[jimmywarting]

it conditional depends on worker_threads (if it's a NodeJS env and the DOMException don't exist globally)
i always try to re-export the global if it exist so it should be quite browser friendly...

[MattiasBuelens]

As of Node 18 (specifically nodejs/node@3f72c72), AbortSignal.reason defaults to an AbortError DOMException, so you can do this:

const DOMException = AbortSignal.abort().reason.constructor;

This has the advantage that it doesn't use any Node-specific APIs (like require), and it works in modern browsers too (although you already have globalThis.DOMException there).

I could try to use that in this polyfill, so we'd have the "correct" DOMException in the latest version of Node without making a Node-specific polyfill. Perhaps you also want to use that in node-domexception? 🙂

[MattiasBuelens]

Ah, never mind, Node 18 also ships with a global DOMException (nodejs/node@e4b1fb5), and that has landed before AbortSignal.reason.

It looks like MessageChannel is available as a global since Node 15. So I can already start using that (without depending on worker_threads), and wait until Node 14 goes EOL next year. 😛

[jimmywarting]

the newest version of my node-domexception just removed the worker_thread solution to one with atob
(requires node v16+)

now it's basically just this:

globalThis.DOMException ??= (() => {
  try { atob(0) } catch (err) { return err.constructor }
})()

[MattiasBuelens]

I'm cleaning up some old issues. Node 16 is now end-of-life, so do you still need DOMException support for it? Otherwise, the current solution with globalThis.DOMException should work in Node 17 and higher.