trpc: [v10] bug: TypeScript not willing to serialize the type of my client

Provide environment information

System: OS: macOS 12.5 CPU: (10) arm64 Apple M1 Pro Memory: 152.64 MB / 32.00 GB Shell: 5.8.1 - /bin/zsh Binaries: Node: 16.16.0 - ~/.nvm/versions/node/v16.16.0/bin/node Yarn: 1.22.19 - ~/.nvm/versions/node/v16.16.0/bin/yarn npm: 8.11.0 - ~/.nvm/versions/node/v16.16.0/bin/npm Browsers: Chrome: 104.0.5112.101 Safari: 15.6

Describe the bug

I am seeing an error in my editor saying: The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed. on my setupTRPC for my Next.js project.

This is coming after a migration from v9 to v10 where I was hoping to see this problem resolve. However, it seems to have moved from my root router to the setupTRPC.

This leads me to believe that the type annotation is getting too long for the TS interpreter in VSCode so it’s punting the effort/complaining. However, I’ll let the real TS genies figure it out. 😄

To reproduce

Providing a minimal reproduction might not be applicable here? This bug occurs because of lots of code, not little code. 😄

Rather, here is a link to my source code.

You’ll find the TS error on this line.

Removing these two falsy declaration values from tsconfig will reveal the error!

Additional information

No response

👨‍👧‍👦 Contributing

🙋‍♂️ Yes, I’d be down to file a PR fixing this bug!

About this issue

Original URL
State: closed
Created 2 years ago
Reactions: 6
Comments: 24 (15 by maintainers)

Most upvoted comments

#2890 cuts the declaration size of the server code in half. I’ll do a release for that soon. But that, combined with the above comment, should fix this issue.

sachinraja on Oct 2, 2022

So #2890 should help but here’s an optimization that you can make:

// instead of this
export type AppRouter = typeof appRouter

// use this
type AppRouterType = typeof appRouter
export interface AppRouter extends AppRouterType {}

this forces TypeScript to emit the named AppRouter type for React instead of fully resolving the type again.

sachinraja on Oct 2, 2022

Released in v10.0.0-proxy-beta.13, please test that and get back to us.

sachinraja on Oct 2, 2022

Is anyone able to create a reproduction of this issue? Would help to diagnose and potentially fixing it

KATT on Sep 25, 2022

Okay. This will be closed soon as we have an automated test that does this with 700 procedures.

Please reopen if you encounter these issues again.

KATT on Oct 12, 2022

Hi, I am running into this issue when i try to export an “SDK” towards our application as a package in a monorepo. The proxy types fail using build, with like 4 routes with 10 procedures each (ouch…). I see that removing generation of declaration is deemed as a workaround, but i don’t see how this would work considering we would like types for the consumers of the externally published SDK package.

While the above trpc-declaration repo doesn’t “look too bad”, as soon as we add some procedures using prisma and add prisma, session etc to the context (similar to create-t3-app examples), we soon end up with 21k+ lines of code in the types. That is with 4 routes as stated above, and as soon as i add a couple more procedures i end up with this error.

I am guessing i need to rethink something with my application, or how i export the external SDK-package. Any idea how to avoid this or to debug further? I tried creating a minimally reproducible repo but this seems to require quite a few components and could even be related to the internal company build-configs we use.

datagutt on Sep 27, 2022