fix(client): accept boolean TLS socket options

[puneetdixit200]

Description

Fixes #3113.

RedisTlsOptions required socket.tls to be the literal type true, which rejected the common Heroku-style configuration where TLS is derived from the URL:

socket: {
  tls: redisUrl.match(/rediss:/) != null,
  rejectUnauthorized: false
}

This widens the TLS socket option type to accept a runtime boolean while preserving the existing runtime behavior: RedisSocket still creates a TLS socket only when options?.tls === true.

I also added a compile-time regression in the client type tests for the Heroku-style configuration.

---

Checklist

• Does npm test pass with this change (including linting)?
• Is the new or changed code fully tested?
• Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?

Verification:

• npm run test:types -w @redis/client
• npm run build
• npm run lint:changed
• git diff --check
• npm exec -w @redis/client -- mocha -r tsx --exit './lib/client/socket.spec.ts' './lib/client/index.spec.ts' ran until Redis-backed hooks tried to start Docker; the non-Docker socket cases passed, then the run failed because Docker is not running locally (~/.docker/run/docker.sock missing).

---

Note

Low Risk
Type-level widening plus internal factory narrowing; TLS is still only used when tls === true, with no change to connection security behavior.

Overview
Fixes compile-time rejection of socket.tls when it is a runtime boolean (e.g. Heroku-style tls: redisUrl.match(/rediss:/) != null), by widening RedisTlsOptions.tls from the literal true to boolean.

Runtime behavior is unchanged: RedisSocket still opens a TLS connection only when options?.tls === true; false continues to use plain TCP/IPC. IPC and TCP branches in #createSocketFactory now narrow options with explicit casts so spreading defaults stays type-safe.

A compile-time regression in create-client.types-test.ts locks in the Heroku-style createClient configuration.

^{Reviewed by Cursor Bugbot for commit 6bdb254. Bugbot is set up for automated code reviews on this repo. Configure here.}

[jit-ci]

Hi, I’m Jit, a friendly security platform designed to help developers build secure applications from day zero with an MVS (Minimal viable security) mindset.

In case there are security findings, they will be communicated to you as a comment inside the PR.

Hope you’ll enjoy using Jit.

Questions? Comments? Want to learn more? Get in touch with us.

[nkaradzhov]

Thanks @puneetdixit200, i will have a look.

[nkaradzhov]

Thanks for the PR. The compile error on the Heroku pattern is real, but widening RedisTlsOptions.tls to boolean collapses the discriminated union — that's why the new as casts were needed in #createSocketFactory — and it makes { tls: false, ca: ... } typeable while silently running plain TCP. That's a permanent loss of type safety to fix a type-ergonomics issue that has workarounds, so we'd prefer not to take this shape.

If you switch scheme dynamically, pass the rediss:///redis:// url and omit socket.tls the url scheme sets it. If you also need TLS sub-options like rejectUnauthorized, use tls: cond ? (true as const) : undefined, which keeps the discriminant. We'll track first-class dynamic-boolean support in #3113 but it needs a design that preserves narrowing rather than a blanket widen. Closing this PR in favor of that — appreciate the investigation.