cache-manager-ioredis-yet
A drop-in Redis and Redis Cluster storage adapter for node-cache-manager, built on ioredis.
Repository Health
Technical Analysis
cache-manager-ioredis-yet is a Redis storage adapter for node-cache-manager, the pluggable caching layer used across the Node.js ecosystem. It wraps the ioredis client to give cache-manager a battle-tested backend that supports both standalone Redis instances and Redis Cluster deployments, handling serialization, TTL semantics, and multi-key operations so applications don’t have to hand-roll a Redis cache store.
The package is maintained as part of Jared Wray’s cache-manager-stores mono repo, which carries forward the legacy v5 Redis stores (this one and its ioredis-free sibling, cache-manager-redis-yet) while newer projects standardize on Keyv. It remains a low-friction way to add Redis-backed caching to a cache-manager-based application without adopting a new caching abstraction.
What You Get
- A
redisStorefactory that returns a cache-manager-compatible Store backed by a freshioredisclient, orredisInsStoreto wrap a client you already constructed. - Built-in Redis Cluster support via a
clusterConfigoption (cluster nodes plus ioredisClusterOptions), with no separate cluster-specific store package needed. - Value serialization through
telejson, so cached values can include richer JavaScript types (Dates, BigInts, cyclic structures) rather than just JSON-safe primitives. - TTL handling that maps cache-manager’s
ttloption directly onto RedisPXmillisecond expirations, for both individualsetcalls and batchedmsetcalls. - A pluggable
isCacheablepredicate so callers can reject specific values (likeundefinedor app-specific sentinels) before they ever reach Redis.
Common Use Cases
- Adding a Redis-backed cache layer to an existing cache-manager application without switching caching abstractions.
- Sharing a cache across multiple Node.js processes or instances behind a single Redis or Redis Cluster deployment.
- Caching API responses, database query results, or computed values with per-key TTLs to reduce load on slower upstream systems.
- Migrating a service that already uses ioredis directly into cache-manager’s store interface without discarding its existing Redis client configuration.
Under The Hood
Architecture
The package is a single-file adapter (src/index.ts) exposing two public factory functions, redisStore (which constructs a new ioredis Redis or Redis.Cluster instance from the options passed in) and redisInsStore (which wraps a client the caller already constructed). Both delegate to a shared internal builder() closure that implements cache-manager’s Store contract — get, set, mset, mget, del, mdel, ttl, keys, reset, isCacheable, and a client getter — over whatever Redis client instance it receives. Serialization is centralized through stringify/parse helpers built on telejson, so every entry point shares one encode/decode path. There’s no dependency-injection framework or extra layering beyond this closure; the design is intentionally flat, so a change to the builder’s contract would ripple through both cluster and non-cluster instantiation and every store operation uniformly.
Tech Stack
Written in strict-mode TypeScript targeting ES2022/CommonJS. Runtime dependencies are cache-manager (peer), ioredis (the Redis/Redis Cluster client), and telejson (structured serialization). The package builds via tsc against a dedicated tsconfig.build.json, and lives as one of two packages in a pnpm workspace mono repo (cache-manager-stores) alongside cache-manager-redis-yet. Tests run with Vitest and @vitest/coverage-v8 against a real Redis instance started through Docker Compose rather than a mock, and CI runs the suite across a Node 20/22 matrix via GitHub Actions with Codecov coverage reporting.
Code Quality
The test suite is extensive for the package’s size — over 350 lines covering set/mset/mget/del/mdel/ttl/reset, TTL expiry timing, custom isCacheable predicates, disconnected-client error propagation, and edge cases like deeply nested and cyclic objects and Date/BigInt round-tripping through telejson. Error handling is mostly a thin pass-through of ioredis’s native promise rejections, with one explicit typed exception (NoCacheableError) for values rejected by the cacheability check. Naming is consistent with cache-manager’s own Store interface, and TypeScript strict mode is enabled, though no committed ESLint configuration is visible in the cloned repo despite ESLint and Prettier being declared as dev dependencies with a lint-staged hook.
API Design
The public surface is deliberately small: call redisStore(options) for a fresh client or redisInsStore(existingClient, options) to reuse one, then hand the result to cache-manager’s caching() — matching the idiomatic cache-manager store pattern with almost no boilerplate. Exported types (RedisCache, RedisStore, RedisClusterConfig) give editors useful autocomplete for both standalone and cluster configurations. The tradeoff is documentation: the package’s own README is minimal (install instructions and a license/fork note only), leaving usage examples to cache-manager’s own docs rather than showing this store’s cluster or isCacheable options directly.