Prisma silently loses nested query type safety on TypeScript ≥ 6.0

[flololan]

Package and version

prisma@^7.1.9

What happened?

Related to #29519, but this issue is about a distinct problem: Prisma does not declare, enforce, or warn about its supported TypeScript version range, even though TS ≥ 6.0 is known to silently disable excess property checking for nested select / include / where / data arguments.

The combination is dangerous:

• The regression ([v7 prisma-client] Non-existent fields in select do not produce a TypeScript error #29519, caused by Widen reverse mapped type properties to fix them being treated as EPC-valid sources microsoft/TypeScript#62722, upstream fix rejected in Excess property check on nested object literals dropped in 6.0 when parameter is a generic "Exact" mapped-type guard microsoft/TypeScript#63515) means invalid nested query fields compile cleanly and only fail at runtime with PrismaClientValidationError.
• @prisma/client has no peerDependencies constraint on typescript, so npm install typescript@6 (or @7) succeeds without any warning.
• prisma generate runs without any diagnostic when an affected TS version is present.
• The docs state a minimum TS version but no maximum / known-broken range. --> https://www.prisma.io/docs/orm/v7/reference/system-requirements#software-requirements

So a routine typescript dependency bump — something Renovate/Dependabot does automatically — silently downgrades the type safety of every Prisma query in the codebase, with zero feedback to the developer. In our codebase this hid real errors (verified by re-checking with TS 5.9.2) that all surface as runtime errors.

Severity assessment

We'd argue this is critical, not a papercut: it's a silent, global loss of the guarantee Prisma is built around, triggered by a dependency update that no tooling flags. Even if the full fix for #29519 takes time, the guard/warning above is cheap and would protect every team upgrading TypeScript today.

Co-authored-by: @AlexDieRobbe

What did you expect to happen?

One or more of:

1. @prisma/client declares peerDependencies: { "typescript": ">=5.1.0 <6.0.0" } (with peerDependenciesMeta optional for pure-JS users), so package managers warn on install.
2. prisma generate detects the installed TypeScript version and prints a prominent warning (or fails with --strict) when it is in a known-broken range.
3. The documentation and release notes clearly state that TS ≥ 6.0 is currently unsupported for full type safety.

Minimal reproduction

1. prisma@7.x + typescript@6.x

2. Any query with a nonexistent field in a nested select, e.g.

   prisma.user.findMany({ select: { id: true, posts: { select: { doesNotExist: true } } } })

3. tsc --noEmit → no error. Runtime → PrismaClientValidationError.

4. Same code with typescript@5.9.2 → compile error as expected.

Environment

• Prisma: 7.9.1
• TypeScript: 6.0.3 (also reproduced on 7.0.2)
• Node: 26

[flololan]

Minimal reproduction repo: https://github.com/flololan/prisma-ts6-repro

git clone https://github.com/flololan/prisma-ts6-repro && cd prisma-ts6-repro
npm install && npm run repro

→ TS 5.9.2: 5 errors · TS 6.0.3: 0 errors · TS 7: 0 errors

One thing we noticed while building the repro that we didn't mention yet: it's not just nested typos that slip through. As soon as a select contains any relation with a nested select/include, excess-property checking breaks for the entire object — including top-level scalars. Remove the relation and the errors come back. The result type also silently drops the invalid field, so downstream access like users.map(u => u.auth0Id) isn't flagged either.

@aqrln @SevInf @millsp — would appreciate a look 🙏