- name
- implement-command
- description
- Use when adding or updating Redis command support in ioredis, including command metadata checks, generator inputs under bin/, generated RedisCommander typings, return and argument overrides, functional command tests, optional tsd coverage, and validation.
# Implement Command
Use this skill when adding a missing Redis command, correcting an existing command signature, changing command return types, or adding coverage for command-specific Buffer, callback, pipeline, or transformer behavior.
## Command Support Map
- `@ioredis/commands`: upstream command metadata consumed by the generator.
- `bin/index.js`: generator entry point for `lib/utils/RedisCommander.ts`.
- `bin/returnTypes.js`: command return type map. Most new commands need an entry here.
- `bin/argumentTypes.js`: command-specific argument shape overrides when metadata or global mapping is insufficient.
- `bin/typeMaps.js`: global Redis argument category to TypeScript type mapping.
- `bin/overrides.js`: manual overloads for signatures the generator cannot express cleanly.
- `bin/sortArguments.js`: argument reordering for commands whose generated order is wrong.
- `lib/utils/RedisCommander.ts`: generated declarations. Regenerate it; do not hand-edit it.
- `lib/Command.ts`: command argument and reply transformer registry. Touch only when transformer behavior is needed.
- `test/functional/commands/<command>.ts`: runtime command coverage.
- `test/functional/transformer.ts`: transformer runtime coverage.
- `test/typing/commands.test-d.ts`: public command typing coverage.
- `test/typing/transformers.test-d.ts`: transformer typing coverage.
## Workflow
1. Establish command scope.
- Normalize command keys to lowercase, matching `bin/returnTypes.js`.
- Resolve command aliases or subcommands before editing.
- Confirm the command exists in `@ioredis/commands`. If it is missing there, stop and report that the metadata package must be updated before ioredis can generate typed command support.
- Identify the minimum Redis server version needed and whether functional tests must be version-gated.
2. Inspect current support.
- Search `lib/utils/RedisCommander.ts`, `bin/`, `test/functional/commands/`, and `test/typing/` for the command and related aliases.
- Inspect nearby command families before choosing types, for example hash expiration commands, sorted-set commands, stream commands, or pub/sub commands.
- Check existing argument and reply transformers before adding new ones.
3. Update generator inputs.
- Prefer `bin/returnTypes.js` for return type corrections.
- Use a string return type for simple fixed replies.
- Use a function return type when replies depend on subcommands, options, or tokens.
- Reuse `hasToken` and `matchSubcommand` in `bin/returnTypes.js` when they fit.
- Use `bin/argumentTypes.js` only for command-specific argument overrides.
- Use `bin/typeMaps.js` only for broad metadata category fixes that should affect multiple commands.
- Use `bin/overrides.js` only when generated overloads cannot express the supported API cleanly.
- Keep command names lowercase in generator maps unless the surrounding file uses another established convention.
4. Regenerate declarations.
- In this repo, use `node bin/index.js` unless `package.json` later adds an explicit generation script.
- Review the generated diff in `lib/utils/RedisCommander.ts`.
- Check the normal method, callback overload, pipeline/transaction shape, and Buffer variant when the command returns strings, arrays, nullable bulk replies, or transformed objects.
- If generation changes unrelated commands, inspect the generator input and do not accept surprising churn without an explanation.
5. Add focused runtime coverage.
- Put command tests in `test/functional/commands/<lowercase-command>.ts`.
- Use `import Redis from "../../../lib/Redis";` and `import { expect } from "chai";`.
- Prefer `let redis: Redis`, `beforeEach(() => { redis = new Redis(); })`, and `afterEach(() => { redis.disconnect(); })`.
- For version-gated command tests under `test/functional/commands/`, import `isRedisVersionLowerThan` from `../../helpers/util`, and use `before(async function () { ... this.skip(); })`; use function syntax when calling `this.skip()`.
- Use unique keys such as `${command}_${caseName}_${Date.now()}`.
- Test the ioredis command surface: accepted argument shapes, option ordering, callback behavior, Buffer variants, and reply shape.
- Keep assertions focused on what ioredis sends and returns. Do not test Redis server internals beyond the smallest deterministic setup needed.
- Assert exact replies when stable; otherwise assert primitive type, nullable behavior, array/object shape, or Buffer conversion.
6. Add typing coverage when useful.
- Add cases to `test/typing/commands.test-d.ts` when the command has nontrivial overloads, return types, Buffer variants, callback typing, or option-dependent replies.
- Cover `expectType<Promise<...>>(redis.command(...))`.
- Add Buffer variant expectations when the command has one.
- Add callback typing for nontrivial return types.
- Use `expectError` only for meaningful invalid signatures.
- Update `test/typing/transformers.test-d.ts` only when transformer APIs are affected.
7. Consider documentation.
- Use the repo `docs-sync` skill when command support changes public signatures, return mapping, examples, or documented command behavior.
- Usually command support is documented through generated declarations and typing tests; update README/docs only when existing prose or examples cover the affected command family or users need version/topology caveats.
8. Validate.
- Run `node bin/index.js` after generator input changes.
- Run the focused functional command test when Redis support is available, using the repo's Mocha pattern with `test/helpers/*.ts`.
- Run `npm run build` when generated declarations, public TypeScript, or generator output changed.
- If typing tests changed, run `npx tsd --files test/typing/commands.test-d.ts` after building.
- Use the repo `code-change-verification` skill before handoff to choose any additional validation.
- If Redis access is blocked by sandboxing, ask for permission to access the local Redis server rather than assuming it is unavailable.
## Completion Report
Report:
- Commands added or updated.
- Metadata/generator inputs changed.
- Generated files changed.
- Functional tests added or updated.
- Typing tests added or updated.
- Documentation decision.
- Validation commands run and results.
- Skipped validation with the concrete reason, including Redis version or local environment limits.
View on GitHub