feat: decouple GLIDE adapter runtime

[lan17]

Summary

Make the Valkey GLIDE adapter depend on the caller's GLIDE runtime capabilities instead of importing a particular installed @valkey/valkey-glide runtime.

Callers now pass the same module namespace that created their standalone or cluster client:

import * as valkeyGlide from "@valkey/valkey-glide";

const client = await valkeyGlide.GlideClient.createClient(config);
const redisClient = createValkeyGlideDialCacheClient(client, valkeyGlide);

Why

GLIDE Script objects are native lifecycle handles. In source-linked workspaces or other dependency layouts, the application and DialCache can resolve different physical GLIDE module instances even when the optional peer range is broad. Constructing scripts through DialCache's module copy can therefore register them outside the runtime used by the caller's client.

The intended ownership flow is now explicit:

caller GLIDE module ──creates──> client
        │
        ├──supplies──> Script constructor
        └──supplies──> Decoder.Bytes
                              │
                              ▼
                    DialCache GLIDE adapter

Design

• Add structural capability types for invokeScript, the releasable script handle, and the minimal runtime namespace.
• Require the runtime namespace as the factory's second argument.
• Remove all GLIDE runtime imports and the published optional peer dependency.
• Keep GLIDE as a development dependency for source typechecking and real-client integration tests.
• Preserve the existing five adapter-owned scripts, idempotent disposal, in-flight disposal protection, binary decoding, wire format, and caller-owned connection lifecycle.
• Keep the core DialCacheRedisClient boundary and Redis/Lua protocol unchanged.

This is capability compatibility, not a promise that every historical or future GLIDE release has identical semantics. Applications remain responsible for passing the module namespace associated with their client.

Migration and release

createValkeyGlideDialCacheClient now requires the GLIDE runtime namespace as its second argument. This intentionally advances the pre-1.0 API through the repository's feat -> minor release rule, so the next planned version is 0.8.0 rather than 1.0.0.

The README installation example no longer pins an application GLIDE version and its timeout references now use the official version-neutral Node API documentation.

Test coverage

• Unit coverage verifies scripts and Decoder.Bytes come only from the supplied runtime while retaining script disposal and protocol validation coverage.
• Packed ESM and CommonJS tests install application GLIDE 2.2.10 alongside a distinct aliased GLIDE 2.4.2 module and assert native constructor/decoder identity.
• Packed TypeScript consumers compile the official GlideClient and GlideClusterClient types against the structural adapter API.
• The exhaustive 16-case Lua protocol suite runs through both real node-redis and Valkey GLIDE clients against both Redis 6.2 and Valkey 8: 64 client/server cases.
• SCRIPT FLUSH recovery explicitly invokes all five production scripts through each client, including tracked read/write and invalidation.
• Raw Lua argument validation runs through each client's native script API, while a separate admin connection is used only to arrange and inspect server state.
• Bidirectional node-redis/GLIDE wire-format compatibility runs on both server engines. The three topology-specific Redis Cluster cases remain node-redis tests.
• Packed adapter entrypoints load successfully before GLIDE is installed, proving the published artifact has no runtime GLIDE import.

Validation

• pnpm check on Node 22.22.0
  • TypeScript typecheck
  • 250 unit tests with coverage gates
  • ESM/CJS builds and declarations
  • packed-package runtime and type consumers
• pnpm test:package on Node 20.17.0
• 69 live integration cases are collected by CI: 64 protocol matrix cases, 2 cross-client interoperability cases, and 3 cluster cases.
• git diff --check

The live Redis/Valkey integration suite was not run locally because it performs database writes; GitHub Actions runs the complete suite against ephemeral containers.