next-sanity icon indicating copy to clipboard operation
next-sanity copied to clipboard

Sanity TypeGen with NextJS: the return type of queries is not correctly resolved

Open lucafaggianelli opened this issue 1 year ago • 1 comments

Describe the bug

When generating types definition via Sanity TypeGen in a NextJS project, the return type of queries is not correctly resolved.

Observing the generated types, they're all correct, but the @sanity/client import is not found (it's used in the declare module), the solution is either to install @sanity/client or use next-sanity in declare module.

To Reproduce

Steps to reproduce the behavior:

  1. Generate a new NextJS + Sanity project
  2. Follow the instruction to setup TypeGen
  3. Create a query
  4. The return type of the query is any

Expected behavior

The query return type should be defined and not any

Screenshots

Which versions of Sanity are you using?

@sanity/cli (global)  3.72.1 (up to date)
@sanity/image-url      1.1.0 (up to date)
@sanity/vision        3.72.1 (up to date)
sanity                3.72.1 (up to date)

What operating system are you using?

MacOS

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

pnpm v9.9.0
v22.10.0

Additional context

Add any other context about the problem here.

Security issue?

Any security issues should be submitted directly to [email protected]. In order to determine whether you are dealing with a security issue, ask yourself these two questions:

  • Can I access something that's not mine, or something I shouldn't have access to?
  • Can I disable something for other people? If the answer to either of those two questions are "yes", then you're probably dealing with a security issue. Note that even if you answer "no" to both questions, you may still be dealing with a security issue, so if you're unsure, just email us at [[email protected]](mailto:[email protected].

lucafaggianelli avatar Feb 03 '25 10:02 lucafaggianelli

I'm open for ideas. But AFAIK if declare module 'next-sanity' is used it won't solve the problem, as the interface is defined in @sanity/client: https://github.com/sanity-io/client/blob/a9d9a71f3b7c0ad02cf8ea2fe439024574b84a8a/src/types.ts#L1315C18-L1315C31 And implemented in client.fetch here: https://github.com/sanity-io/client/blob/a9d9a71f3b7c0ad02cf8ea2fe439024574b84a8a/src/types.ts#L1318-L1321 Changing these in a way that can work for next-sanity, while still support projects that install @sanity/client directly, is non-trivial and it's difficult to justify spending a large effort on it given it has known workarounds, like running pnpm install @sanity/client 😅

This is typically a problem in pnpm and modern yarn, as they won't create the local ./node_modules/@sanity/client path unless you declare @sanity/client in either dependencies, devDependencies or peerDependencies. As you say, the easiest way to solve this is pnpm add @sanity/client. But if you're only doing this for typegen, it feels unnecessary, and perhaps adding this to your .npmrc is a better option:

public-hoist-pattern[] = @sanity/client

I've tried to change @sanity/client to a pure peer dependency of next-sanity to see if it helps, but it doesn't (you can try it yourself with [email protected]). Other approaches, like having a separate dummy package @sanity/client-queries, that exports the SanityQueries interface, we end up with the same package manager problem where TypeScript can't find the types unless it exists in ./node_modules/@sanity/client-queries, and it won't unless you install it in pnpm.

stipsan avatar Feb 13 '25 14:02 stipsan