fix: subscribe should be of type string

[mmkal]

arguments for SUBSCRIBE were in the wrong format, which caused this bug: mmkal/handy-redis#46

this change makes them match unsubscribe: https://github.com/antirez/redis-doc/blob/c882f1d3a767a096453489b00d7ec5bcc2eceaa7/commands.json#L2997-L3010

[itamarhaber]

Hello @mmkal

I understand the PR and accepting it will not be a problem in my opinion. That said, other commands have similar definitions, although the arrays' lengths are > 1 - how does you client handle that?

[mmkal]

Hi @itamarhaber, thanks for the reply. I'm curious which other commands you're referring to? The client parses arguments looking like ["key", "key"] as tuples of length two, so in typescript an array like ['foo', 'bar'] is expected, and that's fine. It was just this one case that was demanding a "tuple" of length one, which doesn't make sense. If there are other arguments with the same problem I will happily also edit them as a follow-up. Even so, the handy-redis client linked flattens all arguments so there is an ugly workaround right now.

[itamarhaber]

This one's the only one with len == 1, but BITFIELD and HSET have such ones with len == 2.

[mmkal]

BITFIELD is working correctly: https://github.com/mmkal/handy-redis/blob/6450195575996c7b1896c569d3bf37b6c5326002/src/generated/interface.ts#L300-L303, since the value in command.json corresponds to the documentation, so the types are used like client.bitfield('mykey', ['GET', 'u4', 0]).

As for HSET - the types the client is currently using are out of date, but should work fine too from looking at the latest docs. If this PR can get merged reasonably quickly, I'll wait for that to update to avoid churn.