G
YouTube TikTok Games
Skip to content

Read declared members while instantiating base types - #65479

Merged
Jake Bailey (jakebailey) merged 2 commits into
microsoft:mainfrom
jakebailey:zod-base-instantiation-declared-members
Nov 14, 2026
Merged

Jake Bailey (jakebailey) merged 2 commits into
microsoft:mainfrom
jakebailey:zod-base-instantiation-declared-members

Conversation

@jakebailey

Copy link
Copy Markdown
Member

This was found while working on #65064 where a zod type was misbehaving in webpack, and it turned out to also happen on main.

#65059 wasn't complete because resolvingObjectTypeStack was pushed to too late with the base types. A fix (maybe too nasty) is to push earlier and then update baseTypes.

Fixes #64605

A class or interface makes its declared members available while its
members are resolved, so that resolving them can read one without
resolving them again. They were only available once its base types were
instantiated, yet instantiating them can need a declared member, when a
type argument of a base type refers back to the type. Zod 4.5 through
4.6.5 declares

    interface $ZodRecordInternals<Key, Value>
        extends $ZodTypeInternals<..., $InferZodRecordInput<Key, Value>> {
        optin?: "optional" | undefined;
    }

where $InferZodRecordInput checks whether Value is optional by reading
optin, which for z.json() leads back to the optin that
$ZodRecordInternals<ZodString, ZodJSONSchema> declares. Resolving its
members again instantiated the same base types until the depth limit,
reporting TS5115 for every use of z.json() in an array or a record, and
for Zod's own declarations without skipLibCheck. The declared members
are now available as soon as the base types are known, before they are
instantiated.

Fixes 64605

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

No active review issues block the change enabling declared-member access during base-type instantiation.

No open issues 🎉

What changed in this PR

Completes the earlier declared-member resolution fix for #64605 by making declared members available while the native TypeScript checker instantiates base types. This addresses circular type resolution in Zod-style recursive types.

Changes:

  • Pushes the object-type resolution stack entry before base-type instantiation, then fills in its base types afterward.
  • Adds a regression case for recursive base-type arguments and updates its type and symbol baselines.
File Description
tsc/​testdata/​tests/​cases/​compiler/​circularDeclaredPropertyAccess.ts Adds a Zod-style recursive base-type regression case.
tsc/​testdata/​baselines/​reference/​compiler/​circularDeclaredPropertyAccess.types Records expected types for the new case.
tsc/​testdata/​baselines/​reference/​compiler/​circularDeclaredPropertyAccess.symbols Records expected symbols for the new case.
tsc/​internal/​checker/​checker.go Makes declared members accessible during base-type instantiation.

Review effort: Balanced

@github-project-automation github-project-automation Bot moved this from Not started to Needs merge in PR Backlog Nov 13, 2026
@jakebailey
Jake Bailey (jakebailey) added this pull request to the merge queue Nov 13, 2026
Merged via the queue into microsoft:main with commit bd5148a Nov 14, 2026
34 checks passed
@jakebailey
Jake Bailey (jakebailey) deleted the zod-base-instantiation-declared-members branch November 14, 2026 00:02
@github-project-automation github-project-automation Bot moved this from Needs merge to Done in PR Backlog Nov 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Author: Team For Milestone Bug PRs that fix a bug with a specific milestone

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

TS5115 in published Zod 4.5–4.6 types after #64372

4 participants