Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
#2,728 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
typescript
Domain
backend

Research direction

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.

Written by the indexing model from the issue text.

Description

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

Dominant language
TypeScript
Stars
2.9k
Forks
157
Avg merge
11h 42m
Merged PRs (30d)
20

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from zenstackhq/zenstack

All issues in zenstackhq/zenstack

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.