tsgo accepts invalid select keys on ZenStack client calls (with repro repo)

[olup]

Summary

With @zenstackhq/orm 3.7.0 and TypeScript native preview (tsgo), invalid select keys are rejected by the explicit FindManyArgs type, but accepted when the same object is passed directly to db.model.findMany(...).

Repro repository: https://github.com/olup/zenstack-select-typing-repro

This issue was created by Codex on human request.

Reproduction

git clone https://github.com/olup/zenstack-select-typing-repro.git
cd zenstack-select-typing-repro
npm install

# Correctly fails: explicit args type rejects the unknown select key
npm run typecheck:args

# Unexpectedly passes: direct client call accepts the same unknown select key
npm run typecheck:client

Expected behavior

Both commands should reject missingField in the select object. A direct db.resource.findMany({ select: ... }) call should be at least as strict as satisfies FindManyArgs<SchemaType, "Resource">.

Actual behavior

typecheck:args fails with:

Object literal may only specify known properties, and 'missingField' does not exist in type ...

typecheck:client exits successfully, accepting the invalid select key.

Why this matters

In an application using generated ZenStack clients, invalid select keys passed type-checking and only failed at runtime with validation errors like Unrecognized keys ... at "select".

Environment

• @zenstackhq/orm: 3.7.0
• @zenstackhq/schema: 3.7.0
• @typescript/native-preview: 7.0.0-dev.20260517.1
• Runtime schema copied from a generated ZenStack v3 schema

[olup]

Additional verification: this is not limited to tsgo.

I updated the repro repo to include both TypeScript 6.0.3 (tsc) and @typescript/native-preview (tsgo) scripts. Results:

# TypeScript 6.0.3: explicit args rejects the invalid select
npm run typecheck:args:tsc   # exits 2

# TypeScript 6.0.3: direct client call accepts the same invalid select
npm run typecheck:client:tsc # exits 0

# tsgo: explicit args rejects the invalid select
npm run typecheck:args:tsgo  # exits 2

# tsgo: direct client call accepts the same invalid select
npm run typecheck:client:tsgo # exits 0

For comparison, when I tested with TypeScript 5.9.3 locally before updating the repro package, tsc rejected both the explicit args case and the direct client call. So this looks like a TypeScript 6 / native-preview interaction with the ZenStack client call signature, not only a tsgo issue.

[olup]

I dug a bit further into the generated declaration types. The likely affected source areas are:

• packages/orm/src/client/contract.ts: model operation signatures like findMany<T extends CrudArgsType<...>>(args?: SelectSubset<T, CrudArgsType<...>>)
• packages/orm/src/client/crud-types.ts: SelectSubset, CrudReturnType, SimplifiedPlainResult, and ModelResult

A local signature experiment suggests the input-side issue is caused by the generic parameter being constrained directly to the broad args type. Under TS 6 / tsgo, this lets the direct client call infer a wide enough T that nested excess-property checks inside select are skipped.

A stricter nested check like this rejects the bad input under both TS 6 and tsgo:

type NoExtraKeys<T, Shape> = T extends object
  ? T & { [K in Exclude<keyof T, keyof Shape>]: never }
  : T;

type PreserveNullish<T, Strict> = Strict | Extract<T, null | undefined>;

type StrictSelect<T, Args> = T extends object
  ? {
      [K in keyof T]: K extends "select"
        ? PreserveNullish<T[K], NoExtraKeys<NonNullable<T[K]>, NonNullable<Args["select"]>>>
        : T[K];
    }
  : T;

Then using it in the parameter type catches select.missingField:

declare function findMany<T extends Args>(
  args?: SelectSubset<T, Args> & StrictSelect<T, Args>
): Return<T>;

However, this is only a partial fix. In my local experiment it catches the invalid input, but it can widen result inference unless the return-side types are also checked. I also observed that an explicit CrudReturnType<Schema, "Resource", "findMany", { select: { id: true } }> still exposes non-selected scalar fields under TS 6 / tsgo in the repro setup, so a robust fix likely needs tests for both:

1. invalid nested select keys are rejected for direct client calls;
2. direct client calls with select: { id: true } return only the selected shape.

So the PR target is probably not just SelectSubset; it may also need adjustment around ModelResult / SimplifiedPlainResult conditional matching under TypeScript 6.

[olup]

I opened a PR with a proposed fix: #2720.

The PR follows the TDD path from this issue:

1. Add a typecheck regression for a direct client call with an unknown nested select field.
2. Tighten SelectSubset for select / include / omit so nested keys receive a strict contextual type under TS6 / tsgo.
3. Keep existing invalid slicing / unsupported-field runtime-validation tests by marking those calls as expected compile-time errors too.

Validation run locally:

pnpm --filter @zenstackhq/orm build
pnpm --filter e2e test:typecheck