I'm working on migrating a homegrown typesafe RPC API over to TRPC and generally enjoying that process. However, one of the pain points I'm running into is that I'm having to rename a whole family of methods because they collide with properties on the TRPC proxy client.

We have a concept of "links" (this thing is linked to this other thing) and they have a whole family of links.createMany style API endpoints.

export const appRouter = router({
  // ...
  links: linksRouter,
});

This is problematic because even at the type level the TRPC client recognises that links collides with an internal property.

const client: "The property 'links' in your router collides with a built-in method, rename this router or procedure on your backend."

I'm glad there's a type error, but this feels like implementation details leaking out and affecting API design in a really unfortunate way.

Obviously there's a valid argument to say that we should just change the name of our model, or we should change the hierarchy of our API (createManyLinks or link.createMany) but this either creates a sweeping change across all of our endpoints or it creates an inconsistency and a gotcha for this one family. Neither of those solutions feel great. It's uncomfortable that our choice of client should require us to restructure the router.

Taking a quick peek at the list of properties behind the scenes, it actually looks like there's might already be a precedent for some collision defence. It uses $request instead of request—although it's possible that the $ is a convention that signifies the same thing as chain$ here, not sure. A previous PR mentions the potential for these collisions: #3693 and a previous user actually ran into the same collision with links (#3530).

This is not entirely dissimilar to something like Prisma, which has to generate a database client where the properties are the names of the tables. It would feel similarly unreasonable if Prisma turned around to say "No you can't use the name 'links' on a Postgres table because it conflicts with how we've written our code".

They solve this problem by generating their client with prefixed built-in methods. For example, you call client.$transaction to begin a database transaction, because client.transaction would potentially collide if I had a database table with the same name.

Now if links was a public property, I'd understand that this probably doesn't affect enough people to be worth a breaking change (and my hunch is that you wouldn't be prepared to make breaking changes to the query, mutation and subscription properties) but would you accept a PR that prefixes the private properties?

Just switching to $links would solve our immediate problem, but for the sake of consistency, we could make the same change for $requestId and $requestAsPromise.

Alternatively, a more sweeping change might be to stop forwarding client requests up to the untyped client and force access to go through that __untypedClient property instead, but I assume the ripple effects would be much worse if there's code out that expects the proxy client and the untyped client to have the same shape.

Either way, if there's a resolution that works for you folks, I'm happy to put in the work to make it happen.