src/platform/PlatformTools.ts (1)

30-36: Consider renaming method to reflect actual behavior.

The method name readPackageVersion implies it returns only the version string, but it actually returns the entire package.json object. This could lead to confusion for future maintainers.

Consider one of these approaches:

Option 1: Rename the method to match its behavior:

-    /**
-     * Reads package.json of the given package.
-     * This operation only supports on node platform
-     */
-    static readPackageVersion(name: string): any {
+    /**
+     * Reads package.json of the given package.
+     * This operation only supports on node platform
+     */
+    static readPackageJson(name: string): any {
         return require(`${name}/package.json`)
     }

Option 2: Keep the name and return only the version:

     /**
-     * Reads package.json of the given package.
+     * Reads the version from package.json of the given package.
      * This operation only supports on node platform
      */
     static readPackageVersion(name: string): string {
-        return require(`${name}/package.json`)
+        return require(`${name}/package.json`).version
     }

If you choose Option 2, you'll need to update the usage in RedisQueryResultCache.ts accordingly.

src/cache/RedisQueryResultCache.ts (1)

310-318: Improve semantic clarity of version detection logic.

The current logic sets redisMajorVersion = 3 for all Redis versions 1-4, which is semantically confusing. The property name suggests it stores the actual major version, but it's actually storing a compatibility marker.

Consider one of these approaches:

Option 1: Rename the property to reflect its purpose:

-    /**
-     * Redis major version number
-     */
-    protected redisMajorVersion: number | undefined
+    /**
+     * Redis API compatibility version (3 for v1-v4 callback-based API, 5 for v5+ Promise-based API)
+     */
+    protected redisApiVersion: number | undefined

Option 2: Store the actual major version and update the compatibility check:

     try {
         const { version } = PlatformTools.readPackageVersion("redis")
         const major = parseInt(version.split(".")[0], 10)
-        if (major <= 4) {
-            // Redis 3/4 set method requires more parameters (key, value, flag, duration, callback)
-            this.redisMajorVersion = 3
-        } else {
-            // Redis 5+ set method accepts fewer parameters (key, value, options)
-            this.redisMajorVersion = 5
-        }
+        // Store actual major version
+        this.redisMajorVersion = major
     } catch {
-        // Default to Redis 3/4 for maximum compatibility
+        // Default to Redis 3 for maximum compatibility
         this.redisMajorVersion = 3
     }

Then update isRedis5OrHigher() to remain unchanged:

private isRedis5OrHigher(): boolean {
    if (this.clientType !== "redis") return false
    return (
        this.redisMajorVersion !== undefined && this.redisMajorVersion >= 5
    )
}

This approach is clearer and more maintainable.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

src/cache/RedisQueryResultCache.ts (1)

319-322: Consider logging version detection failures for easier debugging.

The catch block silently falls back to Redis 3 without any diagnostic information. In production environments, this could make it difficult to troubleshoot version detection issues or understand why a particular behavior was chosen.

Apply this diff to add logging:

     } catch (error) {
         // Default to Redis 3/4 for maximum compatibility
+        this.connection.logger.log(
+            "warn",
+            `Failed to detect Redis version, defaulting to 3: ${error}`,
+        )
         this.redisMajorVersion = 3
     }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

src/cache/RedisQueryResultCache.ts (1)

308-319: CRITICAL: Redis v4 uses Promises, not callbacks. Change condition to major <= 3.

Node Redis v4 introduced breaking changes where all methods return Promises instead of using callbacks. The current code at line 313 treats Redis v4 the same as v3 (callback-based), which will cause runtime failures.

Apply this diff to fix the API version detection:

-        if (major <= 4) {
-            // Redis 3/4 set method requires more parameters (key, value, flag, duration, callback)
+        if (major <= 3) {
+            // Redis 3 uses callback-based API
             this.redisMajorVersion = 3
         } else {
-            // Redis 5+ set method accepts fewer parameters (key, value, options)
+            // Redis 4+ uses Promise-based API
             this.redisMajorVersion = 5
         }

src/platform/PlatformTools.ts (1)

30-39: Consider adding error handling for robustness.

The method will throw if the package is not installed or doesn't have a package.json. While the current caller (RedisQueryResultCache.detectRedisVersion) is protected by prior validation in loadRedis(), consider wrapping the require in a try-catch for defensive programming and clearer error messages.

Apply this diff to add error handling:

 static readPackageVersion(name: string): {
     version: string
     [key: string]: any
 } {
-    return require(`${name}/package.json`)
+    try {
+        return require(`${name}/package.json`)
+    } catch (err) {
+        throw new TypeError(`Failed to read package.json for "${name}": ${err.message}`)
+    }
 }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: alumni
Repo: typeorm/typeorm PR: 11581
File: docs/docs/drivers/mongodb.md:9-13
Timestamp: 2025-07-27T17:29:18.547Z
Learning: TypeORM is compatible only with mongodb@^6, not v4 as previously suggested. The package.json file contains the authoritative peer dependency information for the MongoDB driver version compatibility.

Learnt from: alumni
Repo: typeorm/typeorm PR: 11581
File: docs/docs/drivers/mongodb.md:9-13
Timestamp: 2025-07-27T17:29:18.547Z
Learning: TypeORM supports MongoDB driver versions "^5.8.0 || ^6.0.0" according to the peerDependencies in package.json. The v4 driver is NOT supported. Always check package.json for accurate peer dependency information.

Learnt from: pkuczynski
Repo: typeorm/typeorm PR: 11681
File: package.json:135-135
Timestamp: 2025-09-24T12:25:58.176Z
Learning: When flagging potentially invalid npm package versions, always verify against the direct npm registry using `npm view <package> version` rather than relying solely on web search results, which can be stale due to caching. Recent releases (within hours/days) may not appear in search indexes immediately.

Learnt from: alumni
Repo: typeorm/typeorm PR: 11581
File: docs/docs/drivers/mongodb.md:9-13
Timestamp: 2025-07-27T17:29:18.547Z
Learning: TypeORM supports MongoDB driver versions "^5.8.0 || ^6.0.0" according to the peerDependencies in package.json. The v4 driver is NOT supported. Always check package.json for accurate peer dependency information.

Learnt from: alumni
Repo: typeorm/typeorm PR: 11581
File: docs/docs/drivers/mongodb.md:9-13
Timestamp: 2025-07-27T17:29:18.547Z
Learning: TypeORM is compatible only with mongodb@^6, not v4 as previously suggested. The package.json file contains the authoritative peer dependency information for the MongoDB driver version compatibility.