connect-redis: the peer dependency is node-redis, not ioredis

The peer dependency is node-redis and nothing else

Two peer dependencies are declared: express-session at 1 or newer, and redis at 5 or newer. That second entry is the whole compatibility story. The documented client is the NodeRedis one, and the reference in the options section points at the NodeRedis repository, with the setup example building its client from a createClient factory and calling connect on it. No ioredis adapter appears in the peer list, the install line or the documentation, so a project already on ioredis has no supported path in. The install command asks for all three packages at once, which is a reminder that this library is a plug-in rather than a server: the store, the session middleware and the client all have to be present.

npm install redis connect-redis express-session

The names disagree slightly along the way. The manifest describes the package as a session store for Connect, while the page itself says it provides Redis session storage for Express.

The license file has no extension and there is no homepage

The tree lists the license as a file named license, lower case and with no extension, next to a readme also named in lower case. The manifest declares MIT as a string rather than pointing at that file, so nothing in the package points a scanner at the text itself. Automated license detection usually looks for a name with a recognised extension, and this one has none. The same absence shows up on the packaging side: there is no homepage key in the manifest and none in the repository metadata either, only a bugs URL and a repository address written in the SSH form. For a package with this many downloads, the one page a scanner would want to link to is the one that is missing.

Three TypeScript packages sit in the dev dependencies

The development dependency list contains plain typescript at version 7, a scoped package named for the TypeScript 6 line at version 6, and ts-node at version 10. Two of those are compilers of different major versions installed into the same tree. The lint script runs all three checks in sequence, a type check with emit disabled, then oxlint over the tree, then a formatting check with oxfmt. The fix script is narrower: it runs the linter with its fix flag and the formatter, and no type check at all, so a change that type-checks wrongly is left for the lint run to complain about rather than being caught automatically.

Vite builds the package and rollup is pinned from above

Both the build script and the prepublishOnly script run vite build, so a library rather than an application is packaged by the same tool most people associate with front-end bundlers, with a plugin alongside it whose job is emitting type declarations. The output is dual format: the manifest declares the package as an ES module, points main at a CommonJS build, points module at the ESM build, and gives each side its own declaration file, a .d.ts for import and a .d.cts for require, wired through an exports map with nested conditions. Underneath that sits a single override pinning rollup to a specific version, which is a way of holding a transitive dependency still across the whole install rather than in one package.

Node 22 is the floor and the types ship with the package

The engines field requires Node 22 or newer, which is the same constraint expressed in a different place: the development dependencies carry type definitions for Node 26. For consumers the only type guidance is a single note, that types are included in the package and that a separate definitions package for this library should not be installed. That note exists because the package used to need one, and a stale install in an existing project will now produce two competing declarations for the same module. The runtime requirement and the bundled declarations are the two constraints a consumer actually meets, and both are stated once.

disableTTL outlives the cookie that pointed at the key

Two options decide how long a session lives in Redis, and they interact badly if you turn off the wrong one. disableTouch, false by default, stops the store from resetting the expiry when a request touches a session without changing it, which cuts a write per request and stops idle users from holding sessions open. The page is candid about the trade: the TTL resets every time a user interacts with the server, and disabling that behaviour helps in some instances, which is the wording used. disableTTL goes further and disables key expiration completely, leaving the user to clean up keys outside the library, under a warning to use it only with an exceptional case in mind. Its own note records the consequence: the setting has no effect on express-session setting cookie expiration. A key with no expiry therefore outlives the cookie that referenced it.

Calling session.save() by hand reads the previous expires value

The TTL is taken from the cookie's expires date when the cookie has one, and from the ttl option otherwise, which defaults to 86400 seconds. The option is typed as either a number or a function of the session data, and the prose adds that it also supports an external callback for dynamic values with access to session data. The ordering warning underneath is the part to remember: express-session does not update expires until the end of the request life cycle, so calling session.save() manually beforehand leaves the store working from the previous value. Anything that shortens a session deliberately, such as a step-up authentication flow, is working against a stale expiry unless the expiry is written before the save.

The prefix stacks on the one you already set on the client

The prefix option defaults to sess: and appends to whatever prefix the client itself carries, so a client configured with its own namespace produces a two-level key. That is worth knowing before you go looking for your keys. The page also explains why separate applications sharing one Redis instance need separate prefixes: the bulk commands express-session exposes, named as length, all, keys and clear, are scoped by the prefix, so a shared instance without distinct prefixes lets one application enumerate or clear another application's sessions. The store's own iteration uses the Redis SCAN command, and scanCount sets its COUNT parameter for the id and all methods, defaulting to 100 per call.

interface RedisStoreOptions {
  ...
  ttl?: number | {(sess: SessionData): number}
}

The serializer option replaces the JSON pair used to encode and decode, and its parse half is allowed to be asynchronous while stringify is not.

Editorial conclusion

connect-redis is a small, well-documented store whose sharp edges are all in the TTL and the bulk commands. Use it if your sessions already live behind express-session and you are on the node-redis client, because ioredis is not a supported peer and the option surface assumes that client. Decide about touch and disableTTL before you launch, because both change how long a key lives and one of them outlives the cookie without saying so. Give every application sharing a Redis instance its own prefix, or the length, all, keys and clear commands will reach across all of them. And read the expires ordering note before you call session.save() by hand, since the TTL you get will be the previous one.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. tj/connect-redis on GitHub