cache-manager-ioredis-yet

A drop-in Redis and Redis Cluster storage adapter for node-cache-manager, built on ioredis.

Library
npm
v2.1.2
3stars
MIT License

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
13/100Needs Attention
Development Activity0
Maintenance0
Community8
Maturity44
Momentum0

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
61/100Good
Architecture70
Code Quality78
Innovation55
Learning Curve40

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 redisStore factory that returns a cache-manager-compatible Store backed by a fresh ioredis client, or redisInsStore to wrap a client you already constructed.
  • Built-in Redis Cluster support via a clusterConfig option (cluster nodes plus ioredis ClusterOptions), 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 ttl option directly onto Redis PX millisecond expirations, for both individual set calls and batched mset calls.
  • A pluggable isCacheable predicate so callers can reject specific values (like undefined or 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.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search