Echo JS 0.11.0

Fair question! Two honest answers:

It started as scratching my own itch — each existing option left me wanting something: amqplib is deliberately low-level (no recovery at all), amqp-connection-manager reconnects the socket but stops at the connection
layer (consumer/channel/topology recovery is still your problem) and hasn't seen much maintenance lately. Rascal is solid but more config-driven than I wanted.

What I tried to do differently was make the reliability claims falsifiable: the CI suite force-kills every connection through the management API on each PR and asserts full recovery — channel pool rebuilt, topology re-asserted,
consumers resubscribed on fresh channels, messages flowing again. Plus some batteries that usually end up as app code: per-key rate limiting, a circuit breaker isolated from consumer failures, poison messages draining to DLQs instead of hot-looping, worker-thread consumers. Two runtime deps,
bring-your-own-logger, no process signal hijacking.

The honest trade-off: other clients have years of production mileage; this one has a test suite and ten days on npm. If you're up for sharing the shortcomings you've hit with other clients, those war stories are exactly what I want shaping the roadmap.

Request/response is a great call. RabbitMQ's direct reply-to
(amq.rabbitmq.reply-to) makes it nearly free given confirms, correlation ids and dedicated channels are already in place — I've opened an issue with a design spec here: https://github.com/pinceladasdaweb/rabbitmq/issues/11 (feedback very welcome). And yeah, Redis for that coordination is fair...

right up until the SPOF bites at 3am. :)

That "I don't quite trust it yet" feeling is exactly where I lived for two years — and what fixed it for me wasn't more coverage, it was one specific kind of test: kill the dependency for real, from the server side, while the library is mid-work, and assert full recovery. For Redis that was CLIENT KILL; for an MS-SQL client I'd bet the bodies are buried around killing the connection mid-transaction. My "pretty thorough" functional tests kept passing while reconnection had literally never worked once.

Two things that let me ship anyway: making the README document what the library does NOT do (mine says the lock is single-instance and not Redlock, in bold — honesty is cheaper than a support ticket), and doing the scary refactors only AFTER the destructive suite existed. So your pending transactions refactor might actually be an argument for writing those tests now, not for delaying the release.

The query ergonomics doc looks genuinely nice. FWIW, "bulletproof before people rely on it" never arrives — other people's workloads are the one test suite you can't write yourself.

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.