Skip to content

Read declared members while instantiating base types - #65479

Open
Jake Bailey (jakebailey) wants to merge 2 commits into
microsoft:mainfrom
jakebailey:zod-base-instantiation-declared-members
Open

Jake Bailey (jakebailey) wants to merge 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

This branch has not been deployed

No deployments
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: Not started

Development

Successfully merging this pull request may close these issues.

TS5115 in published Zod 4.5–4.6 types after #64372

3 participants