My only questions are what features of this rely specifically on Node.js that prevent use with Deno, Bun or Browsers?
As well as, the suggestion that with the TS source, it would be trivial to also publish to JSR as well as NPM.
Great question — it made me go audit the code, and the answer surprised even me.
There was exactly ONE Node-specific API in the whole core: node:crypto for randomUUID. As of v0.5.2 (just published) it's gone — replaced by the web-standard globalThis.crypto.randomUUID(). The core now uses no node: imports at all; what remains are modern-runtime features shared by Deno, Bun and browsers: AbortSignal.any, Error.cause, plain timers and Date.now. No EventEmitter (the typed emitter is hand-rolled), no process, no Buffer, no unref.
The engines: node >= 22 field reflects what I test on (native node:test runner, CI on 22/24), not a constraint of the code — Deno and Bun should run it fine, but I won't claim "supported" until cross-runtime CI proves it. That's now on the roadmap, together with JSR publishing: fair point about the TS source making it natural. Both land once the API stabilizes at 1.0 — supporting two registries' expectations before the API settles is where the hidden cost lives.
Thanks for pushing on this — if you try it on Deno or Bun before I get the CI there, an issue with what you find would be gold.