feat(client): add INCREX and INCREXBYFLOAT commands

[nkaradzhov]

INCREX is the integer-only path — both RESP2 and RESP3 return : integer replies in BYINT mode, so the declared return is [NumberReply, NumberReply] with no transform. Setting NUMBER:String opts the user into precision-safe string output via the decoder for values past Number.MAX_SAFE_INTEGER. by, lowerBound, and upperBound accept RedisArgument | number so callers can pass big-int strings directly.

INCREXBYFLOAT is the float-only sibling. Its wire reply differs by protocol ($ bulk string in RESP2, , double in RESP3);

Also bumps the docker test image to custom-26235535976-debian across all packages so CI picks up a server build that includes the latest INCREX API (SATURATE flag).

Integration tests cover both protocols and the precision opt-in.

Description

Describe your pull request here

---

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)?

---

Note

Low Risk
Additive command definitions and test/CI image tag updates; no changes to auth, persistence, or existing command behavior.

Overview
Adds Redis 8.8 INCREX support to the Node client: increx for integer increments (optional BYINT, bounds, SATURATE, TTL/ENX/PERSIST) and incrExByFloat for BYFLOAT, both registered on the public command surface with broad unit and integration tests (including RESP2/3 and large-integer NUMBER:String mapping).

CI and package test defaults switch the 8.8 Redis Docker tag from 8.8-rc1 to custom-26235535976-debian so tests run against a server build that includes the current INCREX API (e.g. SATURATE).

^{Reviewed by Cursor Bugbot for commit a8c6bed. Bugbot is set up for automated code reviews on this repo. Configure here.}

[PavelPashov]

INCREXBYFLOAT stringifies RESP3 doubles after they’ve already been decoded as JS numbers, so precision may already be lost.

Does it make sense to decode RESP_TYPES.DOUBLE as String for this command, or document that precision requires:

withTypeMapping({ [RESP_TYPES.DOUBLE]: String })

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit 596f77e. Configure here.}

[cursor]

INCREXBYFLOAT RESP3 missing transform returns numbers not strings

High Severity

INCREXBYFLOAT declares per-protocol transformReply but both RESP2 and RESP3 entries are undefined. RESP2 happens to work because bulk strings are already JS strings, giving [string, string]. RESP3 doubles are decoded as JS number before reaching the caller, so the result is [number, number] — contradicting the PR description's promise of normalized [string, string] output and silently losing precision for values beyond Number.MAX_SAFE_INTEGER. The RESP3 slot needs an actual transform function that stringifies the decoded doubles.

 

^{Reviewed by Cursor Bugbot for commit 596f77e. Configure here.}