GROQ rest operator in array projection breaks Sanity typegen

[igorexa34314]

Describe the bug

Sanity typegen generates incorrect TypeScript types when using the rest operator (...) inside an array projection in GROQ.

The GROQ query itself works correctly at runtime, but the generated types do not match the actual returned data, which breaks TypeScript typings downstream.

To Reproduce

GROQ query using rest operator inside array projection:

*[_type == "page"]{
  pageContent[] {
    ...,
  },
}

Running sanity typegen generate produces incorrect or incomplete types for pageContent.

{
   pageContent: Array<unknown> | null;
}

Expected behavior

The generated TypeScript types for pageContent should be identical to the ones produced when using a direct array projection, since the query results are equivalent.

Working version:

*[_type == "page"]{
  pageContent[],
}

And the types that should be generated from this query:

{
    pageContent: Array<{
      _key: string;
    } & Cta | {
      _key: string;
    } & Explanation | {
      _key: string;
    } & Hero | {
      _key: string;
    } & Holders | {
      _key: string;
    } & PageText> | null;
}

Actual behavior

The query using { ... } inside the array causes typegen to:

• generate incorrect field types
• lose discriminated union information, or produce overly generic / broken typings for array items

This results in type errors in consuming code despite the query being valid and working at runtime.

Which versions of Sanity are you using?

@sanity/cli (global)                    5.8.1 (up to date)
@sanity/ui                             3.1.11 (up to date)
@sanity/vision                          5.8.1 (up to date)
sanity                                  5.8.1 (up to date)

Which versions of Node.js / npm are you running?

npm: 11.6.2
Node: v24.13.0

[pedrobonamin]

Hello @igorexa34314 thank you for reporting this issue.
Now we got a dedicated repo for typegen, will move this issue there so they get visibility.

Thank you!

[igorexa34314]

It seems like hoisting of schema types feature causes this regression.
It worked as expected until Sanity v4.15.0, this release breaks extracted schema for me. Running typegen with the old schema fixes the problem.

[kbrabrand]

@igorexa34314 I've tried reproducing locally, with a document schema type with an field defined as an array of mixed object types. In my case the generated schema.json didn't change for the minor versions @ v4, but changed quite a bit after v5 – that is expected and related to improved type hoisting.

The generated types are correct for me in all minor versions from 4.14 and up until the v5 release. Also correct all the way up to the latest version.. 🤔

To get further in debugging this I need to have a look at the schema.json file. Would you be ok with sharing both the one that works, and the broken one with me?

[igorexa34314]

@kbrabrand Sure, I have added you to repo https://github.com/igorexa34314/sanity-typegen-issue-45.

[kbrabrand]

@igorexa34314 Based on your schema.json it looks like you've defined your types as document types. Like this:

defineType({
  type: 'document',
  name: 'hero',
  fields: [
    defineField({
      type: 'string',
      name: 'title',
    }),
    ...
  ]
})

Could that be correct? Document types are not intended to be used as field types. It's an anti pattern and something that we've discussed not allowing, but currently it works. If you change your type definition to look like this it should work:

defineType({ 
  type: 'object', // <- instead of document
  name: 'hero', 
  fields: [...] 
})

Document types are intended for documents existing as a separate entity with its own _id etc., while the object types are ment to be used the way you're using them. If what you wanted was to have reusable heros you can have a hero document type and use a reference to it instead.

I'll follow up internally around better warnings in the schema validation and patching this in addition to patching it in the type generation.

[igorexa34314]

@kbrabrand Thanks a lot! ❤️
Changing type definitions from {type: 'document' to {type: 'object'} fixes my problem.

[kbrabrand]

Glad to hear, @igorexa34314. It'll be supported soon (PRs awaiting review), but as mentioned it's an anti-pattern, so best to avoid. Will soon get a validation warning too.

Thanks for flagging!