bug: Getting "property collision with a built-in method" in client apps when used trpc server with nestjs about trpc HOT 6 CLOSED

You have incorrect usage of createRouterFactory. You should pass your router to createCallerFactory like this:

const createCaller = createCallerFactory(appRouter)

See https://github.com/t3-oss/create-t3-turbo/blob/main/packages/api/src/index.ts#L14

and then you create a caller with the context:

const caller = createCaller(createContext)

See https://github.com/t3-oss/create-t3-turbo/blob/main/apps/nextjs/src/trpc/server.ts#L21

I don't know how to do this with your Nest.js setup, but it looks like you have your api as a separate server so you probably shouldn't be using server-side calls.

Fix that up in your repro (preferably make it smaller since it's quite hard to find a trpc bug in a repo of that size) then I can look again

from trpc.

@juliusmarminge Thank you for quick response and pointing out my mistake.

Yes, I have a separate server app that has "nestjs + fastify" setup, which I intend to use with my expo app.
My main goal is to make "expo" app work with "nestjs + fastify" server app, "nextjs" app is not my primary concern.

The packages/api however just contains the logic to combine all tRPC sub-routers to AppRouter.
This packages/api is being used by both apps/nextjs and apps/server.

I have managed to get appRouter instance from packages/api and corrected the usage of createCallerFactory in apps/nextjs. I have pushed the fix in the same repo: https://github.com/akashdevcc/zero-stack

Now, the nextjs web app is compiling and running successfully (but with one warning "Critical dependency: the request of a dependency is an expression" in nestjs packages).
Also, expo app is working with both nextjs and nestjs server.

But, the main issue of the "property collision" TypeScript error still remains, both in "nextjs" and "expo" apps.
due to which I am not getting auto-complete of tRPC query/mutation in the client apps, which is the main benefit of using tRPC.

from trpc.

Hey 👋

We appreciate you taking the time to report this issue.

Unfortunately, we don't have the capacity to assist here as this issue does not seem to be related to tRPC itself.

For effective assistance, reopening the issue with a reproduction repository that proofs there's an issue in tRPC would be immensely helpful. Alternatively, you can try to get help on our Discord or in GitHub Discussions.

Thank you for your understanding and cooperation!

from trpc.

Hi @KATT

Thank you for the great work you have done with tRPC. I know the core team must be busy with v11 release.

I will try to get help on Discord and GitHub discussions. But if it's possible for core team members (@KATT @sachinraja @Nick-Lucas) to have a look whenever they get capacity, please do. As I believe many developers would want a monorepo setup with dependency injection to support large complex projects.

from trpc.

@KATT
Also, when I was trying to dig deeper into the issue, I saw that after the build of my packages/api, the generated dist/index.d.ts shows _trpc_server_dist_unstable_core_do_not_import.BuiltRouter as /*unresolved*/ (refer to line no. 44 in the attached screenshot).

This is same for other types which I needed to import from "unstable core" i.e.

DecorateCreateRouterOptions
TRPC_ERROR_CODE_NUMBER
QueryProcedure
MutationProcedure
Router
RouterCaller

Whereas the inferRouterInputs and inferRouterOutputs which are also part of "unstable core" are able to get resolved successfully. May be because they have been exported here directly.

Also, it has been mentioned in comments of file unstable-core-do-not-import.ts "If you seem to need to import anything from here, please open an issue"

I am not an expert in typescript, but I think making these types available out of "unstable core" just like inferRouterInputs and inferRouterOutputs, will resolve this issue.

This issue might not be coming for those who are using ES modules, because monorepo trpc examples are working perfectly like t3-oss/create-t3-turbo but in my case I had to use "commonjs" because of "nestjs and fastify" server setup.

from trpc.

This issue has been locked because we are very unlikely to see comments on closed issues. If you are running into a similar issue, please create a new issue. Thank you.

from trpc.