Issue with monorepo architecture ant tRPC
Hi, we had an issue with batched requests that if we batch some requests they produce a TRPCClientError which says
Cannot read properties of undefined (reading 'messsage') so I have read that at least error problem was fixed in newer versions, so we tried to update version, but then the builds started to fail. We get this error (photos in the thread) and more information
23 Replies
one solution to solve this was to define router type with
AnyRouter that you export, however then I get this error in my client
Could you share where you’re setting up your transformer on the API?
I would focus on fixing the backend errors first, the frontend might give useless errors until the backend itself is compiling ok
Putting a # in your import names is something I haven’t seen before though, is that a valid import character?
Yeah, it's aliased path, and everything worked before bumping up version
here I set transformer
and as for the router I import it in different file and add routes
Does your tsconfig for the API have allowSyntheticDefaultImports enabled?
Might not affect here, but it's solved many weird issues with default imports for me
Also consider reloading your typescript language server (or just window) each time you tweak something, it can just be your editor being broken
yeah just tried, didn't do anything :/
Yeah, I'm always reloading extension host and ts server (on vs code)
Can you try commenting out all your routes in appRouter and just adding one really trivial one?
just a hello world query
and it is weird that one error is mad on superjson since versions between services are literally the same (checked even node_modules), and as for the AnyRoute maybe the type isn't that decent? 😄 Any way to describe router type differently?
damn, tried this
and still get same error 😄
Is TS locating superjson in a different monorepo package than it's being imported from?
Are you sure it's actually installed in the package it's being imported into?
It's locating in the same one
What does #content-base/../student-backend/etc do then?
Something is looking really weird
Also noticed this comment: https://github.com/microsoft/TypeScript/issues/42873#issuecomment-1435957417
GitHub
The inferred type of "X" cannot be named without a reference to "Y"...
Bug Report 🔎 Search Terms inferred type cannot be named, symlink node_modules 🕗 Version & Regression Information I'm verifying the problem on the typescript@4.1.3. I've not ...
There might be some other suggestions on that page to help
It's looking like quite a specific issue to how you're set up
Yeah I was looking into this one this morning, didn't found anything that would help :/ Talking about the route since I'm using clients in my API's to communicate between backend services, maybe it's using that in build
but the end of that route is still node_modules of the service that is throwing this issue, so it's using his own superjson
UPDATE*
If I add
import type {} from 'superjson'; on top of every route then it removes these errors at least on vs code, however if I try to build I still get errors, but then with other packages like fastify, fastify types and etc... 😄 So it's a rabbit hole
any way to describe routes? Without writing typescript types from scratch?
also how much it would impact performance If we would go to older versions and don't use batch requests?You’re honestly just doing something very weird in your repo, but without looking at the whole thing I couldn’t tell you exactly what
Just those imports in the errors look suspect
Might be that superjson isn't added as a dep to all packages
Or mismatching versions
Superjson is added in all services and share the same version. As for @Nick Lucas answer, there would be an additional question- if our backend services needs to communicate between themselves, is creating a trpc client a good path? Because this is what I am doing rn, that's why there are these paths.
So if you want them hosted separately then they’ll each have their own router and a client for each service they want to talk to. If you want them hosted together you should use createCaller to invoke without hitting the network layer
It can be a code smell though, beware cyclic dependencies.