Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

GetPayload utility types should accept readonly (as const) include shapes

Aperta
  • Qualcosa non va?
#2,728 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
typescript
Ambito
backend

Direzione di ricerca

Start from the $SelectIncludeOmit constraint and the generated ModelGetPayload<Args> utility type named in the issue; the fix relaxes that constraint (or the payload computation consuming it) so readonly arrays and properties from as const are accepted. Reproduce with the 6-level postInclude snippet and a type-level assertion that PostGetPayload<{ include: ReturnType<typeof postInclude> }> resolves without DeepMutable. Done when that typecheck test passes and existing payload type tests still hold.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Description and expected behavior
When a findUnique/findMany query uses deeply nested include (6+ levels), TypeScript's inference depth limit causes the return type to collapse to any. The recommended workaround is to use the generated ModelGetPayload<Args> utility type to compute the payload type at the type level, bypassing inference.

However, to preserve literal true values (required for GetPayload to resolve which relations are included), the include object must use as const. This produces readonly types, which are rejected by GetPayload's constraint ($SelectIncludeOmit).

A query 6+ levels deep:

function postInclude(postId: string) {
  return {
    author: true,
    sections: {
      include: {
        blocks: {
          where: { type: { in: [BlockType.TEXT, BlockType.IMAGE] } },
          include: {
            comments: { where: { postId } },
            revisions: {
              orderBy: { createdAt: "asc" },
              include: {
                changes: {
                  include: {
                    annotations: { include: { tag: true } },
                  },
                },
              },
            },
          },
        },
      },
    },
  } as const;
}

Current workaround
Users must define a recursive DeepMutable utility type to strip readonly before passing to GetPayload:

type DeepMutable<T> =
  T extends ReadonlyArray<infer U>
    ? DeepMutable<U>[]
    : T extends object
      ? { -readonly [K in keyof T]: DeepMutable<T[K]> }
      : T;

// ❌ Fails: readonly types from `as const` don't satisfy $SelectIncludeOmit
type Broken = PostGetPayload<{ include: ReturnType<typeof postInclude> }>;

// ✅ Works but requires boilerplate DeepMutable
type FullPost = NonNullable<
  PostGetPayload<DeepMutable<{ include: ReturnType<typeof postInclude> }>>
>;

Additionally, the findUnique call itself requires @ts-expect-error because the deeply nested include also fails inference at the call site, and an explicit return type annotation is needed:

async function fetchPost(
  postId: string,
  db: ZenDb,
): Promise<FullPost | null> {
  // @ts-expect-error -- findUnique inference hits TS depth limit on deeply nested includes
  return db.post.findUnique({
    where: { id: postId },
    include: postInclude(postId),
  });
}

// Downstream types now resolve correctly
type Section = FullPost["sections"][number];
type Block = Section["blocks"][number];
type Revision = Block["revisions"][number];
type Change = Revision["changes"][number];
type Annotation = Change["annotations"][number];

Expected behaviour
GetPayload should accept readonly include shapes natively:

// Should just work — no DeepMutable needed
type FullPost = NonNullable<
  PostGetPayload<{ include: ReturnType<typeof postInclude> }>
>;

Environment (please complete the following information):

  • ZenStack version: 3.7.2
  • Database type: Postgresql
  • Node.js version: 24x
  • Package manager: npm

Additional context
Context
This pattern is needed when:

Schema has deeply nested relations (6+ levels: Post → Section → Block → Revision → Change → Annotation → Tag)
Users want to extract typed helpers from query results (e.g., type Block = FullPost["sections"][number]["blocks"][number]
The ReturnType approach silently resolves to any due to TS depth limits

Lingua principale
TypeScript
Stelle
2.9k
Fork
157
Merge medio
11h 42m
PR unite (30g)
20

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di zenstackhq/zenstack

Tutte le issue di zenstackhq/zenstack

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.