Feedback Request: Type Mapping in node-redis

[nkaradzhov]

Hi folks! We are looking for feedback on the Type Mapping API in node-redis:

• client.withTypeMapping() and
• createClient({ typeMapping: ... })).

Today, this area has its costs for the project:

• it slows TypeScript compilation,
• introduces a lot of internal complexity,
• and is difficult to maintain consistently across commands and modules.

In order to make informed decision on long-term direction, we need to better understand how people are using the API in practice.

What we need from this discussion

1. If you actively use type mapping and depend on it, please share concrete examples so we can understand what it enables for you.
2. If you do not use it, please share that too by reacting with a 🚀 .
3. If you hit problems, edge cases, or confusing behavior, please include details.

Context on possible alternatives

We are exploring two alternatives which focus on more powerful parsing control but they also have tradeoffs.

Two short examples of the direction, which revolve around having an optional last argument to each command that provides the command options:

• Per-command parse mode. Add a parseMode: 'resp'|'raw' prop CommandOptions

//if you dont provide a parseMode, you get the normal javascript-idiomatic response of the command
cosnt value = await client.get("k") // string

//if you set parseMode to 'raw', you get the complete RESP message in ENCODED form
await client.get("k", makeOptions({ parseMode: "raw" })) // Buffer -> '$5\r\nvalue\r\n'

//if you set parseMode to 'resp', you get an intermediate javascript representation of the RESP message
await client.get("k", makeOptions({ parseMode: "resp" })) // { type: BLOB_STRING, value: Buffer -> 'value' }

• Per-command custom parser. Add a parser: (b: Buffer) -> T prop to CommandOptions

//if you dont provide a parser, you get the normal javascript-idiomatic response of the command
cosnt value = await client.get("k") // string

//if you set parser, the return type of the command becomes what the return type of the parser is
//the library will still provide couple of useful ready-made parsers
import { rawParser, respParser } from '@redis'

await client.get("k", makeOptions({ parser: rawParser })) // Buffer -> '$5\r\nvalue\r\n'
await client.get("k", makeOptions({ parser: respParser })) // { type: BLOB_STRING, value: Buffer -> 'value' }

//but you also have the option to write your own custom one
const myParser: Parser = (buf: Buffer) => buf.length
await client.get("k", makeOptions({ parser: myParser })) // number

Tradeoffs include:

• users need to understand how RESP works in order to write any more complex parser,
  • that is mitigated by the respParser which can be used as a prestep to translate the raw RESP message into the intermediate representation
• handling RESP2/RESP3 differences more explicitly.
  • some commands have different responses in RESP2 and RESP3. A parser written with RESP2 in mind might not work properly for RESP3
• no global catchall parsing ability
  • right now users can say withTypeMapping({[BLOB_STRING]: Buffer}) and that will change return types of all commands that return string to return Buffer.
  • a parser could be added as a global commandOption, but it will most probably work for only certain commands that have similar return shapes.

No final decision has been made. This discussion is intended to guide that decision based on your feedback.

What to include in your comment

• Node version and whether you use JavaScript or TypeScript.
• Which type mapping features you use today.
• A short snippet showing your current usage.
• Why the current approach is valuable to you (or why it is not).
• Any bugs, inconsistencies, or friction points you have hit.
• Whether you would adopt a new parsing API, and under what conditions.
• Propose an API