cacheable: eight specialized Node.js caching packages in one repository

Eight packages, one repository, each with a separate npm install

The cacheable repository is a mono repo containing 8 distinct npm packages, each addressing a specific caching pattern in Node.js applications. They share a common foundation: all build on Keyv, a key-value storage library that provides a unified interface over multiple backends. Installing one does not pull in the others, and each has its own npm name and its own documentation page at cacheable.org.

The flagship package is cacheable, described as a next generation caching framework built from the ground up with layer 1 / layer 2 caching. cache-manager handles the pattern used by NestJS and similar service frameworks, including a wrap method for function result caching. cacheable-request wraps Node.js native HTTP requests to add RFC-compliant cache support. flat-cache provides fast in-memory caching backed by file store persistence. file-entry-cache is a lighter variant for tracking file metadata, suited to processes that only need to reprocess files changed since their last run. @cacheable/node-cache is a maintained built-in replacement for the older node-cache npm package, targeting codebases that already use the node-cache API and need a version with continued upkeep. @cacheable/memory adds LRU support for pure in-memory caching without any persistence to disk. The utility library @cacheable/utils rounds out the set, offering hashing, shorthand time notation and memoize.

cacheable's two-tier design separates a fast path from a backing store

cacheable organizes caching into two layers. Layer 1 is the fast path, and layer 2 provides a backing store. The package table describes this as layer 1 / layer 2 caching without detailing the backend options in the README, and the documentation for configuration is at cacheable.org. This two-tier pattern matters when cache hits need to be as fast as possible while still surviving process restarts or being shared across multiple processes.

cache-manager follows a different model. It is described as used in services such as NestJS and includes a wrap feature. A wrap call typically covers a data-fetching function and returns a cached result on subsequent calls with the same key. Neither the README's table entry nor any repository file included here specifies how cache invalidation or TTL is configured, so cacheable.org is the necessary starting point before writing production code against either package.

Installing from npm, since the README gives no per-package commands

All 8 packages are published to npm under the names shown in the repository table. The README gives no per-package install command, but the npm badge links in the table each point to the package listing on npm.

The npm names are: cacheable for the main two-tier framework; cache-manager for NestJS-style integration; cacheable-request for HTTP response caching; flat-cache and file-entry-cache for the disk and file-metadata variants. For the drop-in node-cache replacement use @cacheable/node-cache. Pure in-memory LRU caching comes from @cacheable/memory, and shared utility functions from @cacheable/utils.

Installations go through your package manager of choice. The repository root specifies [email protected] in the packageManager field of the root package.json, but end users install individual packages via npm, yarn or pnpm according to their own project setup.

cacheable-request adds RFC-compliant caching to Node.js native HTTP requests

cacheable-request takes a different approach from the other packages. Rather than caching arbitrary values behind a key, it wraps Node.js native HTTP requests and adds RFC-compliant caching behavior. Responses with appropriate cache headers are stored and returned from cache on subsequent identical requests, following the caching rules defined in the HTTP specification.

The repository tags cacheable-request under the topic rfc-72, and the package table describes it as providing RFC compliant cache support. Projects that make repeated HTTP requests to third-party APIs where responses are cacheable benefit most from this approach. Projects that control both the client and the server, and that already have a custom caching layer at the application level, have no need for an HTTP-layer cache wrapper.

flat-cache persists to disk after restart; @cacheable/memory loses data on exit

Two packages serve pure caching without the two-tier layer structure. flat-cache describes itself as fast in-memory caching with file store persistence. That last phrase is the important distinction: values stored in flat-cache write through to a file, and they survive process restarts. @cacheable/memory, by contrast, provides in-memory caching with LRU support and no mention of persistence. Each restart starts with an empty cache.

file-entry-cache is narrower still. It is described as lightweight and designed for processes that only need to reprocess files that have changed since the last run. That description fits build tools and linters, where the goal is tracking which source files have been modified rather than general-purpose key-value storage. Using file-entry-cache for application caching would be the wrong fit.

@cacheable/node-cache replaces a package that the cacheable project describes as needing a maintained alternative

The name @cacheable/node-cache and its description, maintained built-in replacement of node-cache, tell a specific story. node-cache is a different, older npm package with its own API. This package replicates that API, giving existing codebases a way to switch to a maintained version without changing application code. Whether the original node-cache package satisfies your maintenance needs is something to verify on npm; the cacheable project describes its version as the maintained alternative.

@cacheable/utils sits at the other end of the scope spectrum. It offers hashing, shorthand time notation and memoize utilities, all described as serving the cacheable ecosystem. These are support functions rather than a standalone caching solution. Installing @cacheable/utils in isolation only makes sense if your project already uses another cacheable package or if those specific utility functions are what you need.

Contributing to the mono repo requires Redis, pnpm and Docker; the root test run covers all packages

Anyone working on this repository needs three things: Redis running via Docker, pnpm build to compile the packages, and pnpm test to run tests and linting together. The docker-compose.yml in the repository root starts a redis service at redis:8.10.1 on port 6379 and a mockhttp service at jaredwray/mockhttp:2.0.0 on port 3737, mapped from internal port 3000. The contributing guide lists the three steps in order:

docker compose up -d
pnpm build
pnpm test

The first command starts Redis and the mock HTTP server as defined in docker-compose.yml. Compiling all packages recursively is what the build step does. Only after both are in place do the tests and linting pass in full.

One point of friction for contributors is that the root test command runs all package tests together. Starting Redis is a prerequisite for that full run, even when a change touches only a package like @cacheable/memory or flat-cache that has no direct Redis dependency. The main README does not document how to run tests for a single package in isolation.

The repository root also contains CLAUDE.md and AGENTS.md entries, which are configuration files for AI coding assistants. Their presence in the top-level entries shows the project uses AI tooling during development, though neither file's contents appear in the main README.

Editorial conclusion

cacheable is the right choice when a Node.js project needs a maintained set of caching primitives and the specific package matches the caching pattern: cacheable for two-tier caching, cache-manager for NestJS-style wrap caching, cacheable-request for HTTP response caching, or @cacheable/node-cache for an existing node-cache codebase. Before adopting any of these, read the individual package documentation at cacheable.org, because the repository README describes each package in a single line. Skip it if your project is not Node.js, or if a direct Redis client covers your needs.

Frequently asked questions

Official sources

1. jaredwray/cacheable on GitHub
2. License: MIT
3. Project website
4. README
5. Releases