feat: implement monitor command

[ArturSharapov]

Reference

• Issue: Implement MONITOR command #183
• Docs: https://redis.io/docs/latest/commands/monitor

Proposed changes

First implemented with a few lines of code, but then extended taking PubSub as an example to meet the project structure/style, reconnection policy, etc.

@uki00a I would appreciate your assistance with covering it with tests, as I couldn't get them running locally.

Example:

const monitor = await redis.monitor()

await redis.ping()
await redis.ping()
await redis.xrange('foo', '-', '+', 3)
await redis.ping()

for await (const { timestamp, args } of monitor.receive()) {
  console.log(`[${timestamp}]`, ...args)
  if (args.length > 1) monitor.close()
}
console.log('Done')

Expected output:

[1735139990.6913076] PING
[1735139990.6922036] PING
[1735139990.6932956] XRANGE foo - + COUNT 3
Done

[uki00a]

@ArturSharapov Thanks for opening the PR! The implementation looks good overall. Just one comment.

[uki00a]

I think it would be better not to duplicate the connection here for the following reasons:

1. to keep consistency with subscribe()
2. node-redis also works that way
   • https://github.com/redis/node-redis/blob/ffa7d2525c6d8bdd24faaad527a3ad0aec2cd8e9/packages/client/lib/client/index.ts#L985-L992

What do you think about this?

[ArturSharapov]

I've been using ioredis historically (which also seems to be 1.5+ times more popular than node-redis on npm).

Unlike node-redis, it does duplicate the connection by default on monitor() which I think was rational because all other commands become unavailable then.

The only positive side of using a single connection I can see is to cover the case when one would want to create redis connection only to perform monitoring and nothing else.

But this comes with a cost, making it dangerous, as it easily leads to unexpected behavior, blocking execution of all other redis commands. For those who are not experienced with redis much or for those coming from ioredis, it would become unclear, why some redis commands just get stuck and take forever to execute; in a large codebase it would be especially challenging to debug. It's also unclear whether the commands you call are accumulated and executed once you terminate the monitor (which can only be done manually), or they are just ignored entirely.

[ArturSharapov]

I would advocate for the duplication of connection as it make it simpler and doesn't "break all things", as well as eliminates potential issues and unforeseen behavior.

That said, what about brining an argument (option) to the monitor() that could make it use the same connection?
To cover the case when one needs to have redis only for monitoring and doesn't need a regular working redis instance to use the rest of the API.

[uki00a]

@ArturSharapov I'm in favor of adding an option to the monitor() 👍

We are planning to support RESP3 in the future, and it would be ideal to have an option of not duplicating a connection to monitor().

I have two suggestions:

• Add reuseConnection option to monitor().
• Make Connection#duplicate a private API for now
  • I'll implement a connection pool in this library and would like to keep Connection#duplicate private until then
  • e.g.)

    redis/connection.ts

    Line 51 in ad96f2c

    [kUnstableReadReply](returnsUint8Arrays?: boolean): Promise<RedisReply>;

[ArturSharapov]

Good call 👍

[uki00a]

@ArturSharapov To run tests locally, you'll need to install redis-cli and redis-server binaries. Your implementation looks good, so if installation is troublesome, I'll add tests in another PR.

Alternatively, CI will also run tests, so you can take advantage of that.