add support for all hash field expiration commands

[sjpotter]

Description

adds the has field expiration commands - for testing purposes, need a docker container that has it in it.

---

Checklist

• Does npm test pass with this change (including linting)?
• Is the new or changed code fully tested?
• Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?

[leibale]

Overall looking good, but:

1. I've made some changes, please review them..
2. Seems like HGETF and HSETF are missing

[sjpotter]

change look fine

[sjpotter]

Overall looking good, but:

1. I've made some changes, please review them..

2. Seems like `HGETF` and `HSETF` are missing

wondering why you didn't do an enum like response for HEXPIRETIME?

[sjpotter]

Overall looking good, but:

1. I've made some changes, please review them..

2. Seems like `HGETF` and `HSETF` are missing

wondering why you didn't do an enum like response for HEXPIRETIME?

I see why, as it returns a negative number on "error" (enum) and any positive number on "success", and can't capture that conception in typescript.

[sjpotter]

otherwise changes looks fine, and I messed up initial tests, thanks for fixing.

[leibale]

We can make an enum for HEXPIRETIME and use a type like

type x = 1 | 2 | number;

I think that some users will find the enum useful..

[sjpotter]

We can make an enum for HEXPIRETIME and use a type like

type x = 1 | 2 | number;

I think that some users will find the enum useful..

so I tried something like that, but it seemed like it ended up being shown as just number (as number is a superset of 1/2)

[leibale]

It's possible, but a bit more complicated than that
https://www.totaltypescript.com/tips/create-autocomplete-helper-which-allows-for-arbitrary-values

and even if we don't use that in the return type, I think that some users will still find the enum useful (something like reply === HASH_EXPIRATION.FIELD_DOES_NOT_EXISTS is more readable than reply === -2)

[sjpotter]

I agree, but I can't seem to get omit to work with NumberReply as NumerReply expects a number subtype, but Omit doesn't seem to return an number that can be used by it, and when I created a type manually without NumberReply, it didn't seem to make a difference in practice, was still just number.

but yes, I created the enum to use, just unsure how to expose it to the user.

export const HASH_FIELD_EXPIRETIME = {
/** The field does not exist /
FIELD_NOT_EXISTS: -2,
/* The field has no expiration time */
NO_EXPIRATION_TIME: -1,
} as const;

[leibale]

Should we do

interface HExpireOptions {
  mode?: 'NX' | 'XX' | 'GT' | 'LT';
}

for "future proofing" (in case there will be more optional arguments)

[sjpotter]

it doesn't really future proof, it just makes it easier if these options are shared between multiple commands. Unsure it adds that much.

[leibale]

the reply is array of

Integer reply: -2 if no such field exists in the provided hash key, or the provided key does not exist.
Integer reply: -1 if the field exists but has no associated expiration set.
Integer reply: the TTL in seconds.

should we create an "enum" (not the TS one) for the -2 and -1 values? IDK if I like having them anymore..

[sjpotter]

an enum can have value to refrer to negative values by name. but isn't that what I did before ala

export const HASH_FIELD_EXPIRETIME = {
  /** The field does not exist /
  FIELD_NOT_EXISTS: -2,
  /* The field has no expiration time */
  NO_EXPIRATION_TIME: -1,
} as const;