Fetch api.orders.getAll with these arguments a,b,c \r\n\r\n```\r\ncomments: \r\n- I left out the comments as I don't know how to document it right, so here are some comments. \r\n- is use proxies to solve the missing key errors. \r\n- Functions are needed making it possible to be `api.orders` and `api.orders()`. \r\n- _path saves the path like `api.orders.getAll`\r\n- When somewhere a function is called, handlers.apply is called. \r\n- this is *an* implementation not *the* implementation, rather a proof of concept. I use the proxy syntax never, but vue's reactivity system uses it.\r\n\r\n## Final notes\r\nI trying my best to make it easy to grasp, Try the code provided in technical details in your own sandbox to understand a little bit better how it works. Personally, I think this is the easiest syntax as it feels like your calling a function on your backend. I also understand this not Graphql like syntax. Potentially you can have multiple client interfaces. To be honest, I only know this library for a couple of days, because Theo appeared in my youtube feed. So I also don't know if this syntax is in line with the vision of trpc. \r\n\r\nAfter all, I still wanted to show this javascript trickery and proposal, especially after the many hours figuring it out. Do not hesitate to ask further questions if something is unclear. \r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n",[3092],{"name":3093,"color":3094},"💡 ideas","bfdadc",2215,"Documentation Proxy Api and @trcp/client","2022-10-04T06:09:12Z","https://github.com/trpc/trpc/issues/2215",0.7045477,{"description":3101,"labels":3102,"number":3103,"owner":3021,"repository":3021,"state":3037,"title":3104,"updated_at":3105,"url":3106,"score":3107},"### Provide environment information\n\n```\r\n System:\r\n OS: macOS 12.6\r\n CPU: (10) arm64 Apple M1 Pro\r\n Memory: 97.91 MB / 16.00 GB\r\n Shell: 5.8.1 - /bin/zsh\r\n Binaries:\r\n Node: 16.13.1 - ~/.nvm/versions/node/v16.13.1/bin/node\r\n Yarn: 1.22.19 - ~/.nvm/versions/node/v16.13.1/bin/yarn\r\n npm: 8.1.2 - ~/.nvm/versions/node/v16.13.1/bin/npm\r\n Watchman: 2022.10.03.00 - /opt/homebrew/bin/watchman\r\n Browsers:\r\n Brave Browser: 107.1.45.127\r\n Safari: 16.0\r\n npmPackages:\r\n @trpc/client: ^10.4.2 => 10.4.2 \r\n @trpc/server: ^10.4.2 => 10.4.2 \r\n typescript: ^4.9.3 => 4.9.3 \r\n```\n\n### Describe the bug\n\nWhen using an zod object with `.catchall()` for the output of a procedure, it will incorrectly infer the type of the object when compiling the code using typescript for usage in another library.\r\n\r\nI've created a minimal example to reproduce the issue. Let's say we have a server with one procedure `test`. This procedure takes as both input and output a z object with a required property `name` and a `catchall()` of `z.unknown`. this should generate the following interface:\r\n\r\n```ts\r\n{\r\n [x: string]: unknown;\r\n name: string;\r\n}\r\n```\r\n\r\nIn most cases it does generate that interface, except for the output model of the trpc client.\r\n\r\nIf we have the following code. \r\n\r\n\r\n```ts\r\nimport { inferRouterInputs, inferRouterOutputs, initTRPC } from \"@trpc/server\";\r\nimport { createTRPCProxyClient } from \"@trpc/client\";\r\nimport { z } from \"zod\";\r\n\r\nconst t = initTRPC.create({});\r\n\r\n// Simple object with name as string and allows any other properties as unknown\r\nconst zObject = z\r\n .object({\r\n name: z.string(),\r\n })\r\n .catchall(z.unknown());\r\n\r\nconst router = t.router({\r\n // Test takes the zObject as both input and output\r\n test: t.procedure\r\n .input(zObject)\r\n .output(zObject)\r\n .mutation(({ input }) => {\r\n return input;\r\n }),\r\n});\r\n\r\n// Client is based on the type of the router\r\ntype AppRouter = typeof router;\r\n\r\n// correctly specifies the input type\r\nexport const input = {} as inferRouterInputs\u003CAppRouter>[\"test\"];\r\n// correctly specifies the output type\r\nexport const output = {} as inferRouterOutputs\u003CAppRouter>[\"test\"];\r\n\r\n// correctly specifies the input type, incorrectly specifies the output type\r\nexport const client = createTRPCProxyClient\u003CAppRouter>({\r\n links: [],\r\n});\r\n```\r\n\r\nIt will generate the following .d.ts bundle:\r\n\r\n```ts\r\nexport declare const input: {\r\n [x: string]: unknown;\r\n name: string;\r\n};\r\nexport declare const output: {\r\n [x: string]: unknown;\r\n name: string;\r\n};\r\nexport declare const client: {\r\n test: {\r\n mutate: (input: {\r\n [x: string]: unknown;\r\n name: string;\r\n }, opts?: import(\"@trpc/server\").ProcedureOptions | undefined) => Promise\u003C{\r\n [x: string]: never;\r\n [x: number]: never;\r\n }>;\r\n };\r\n};\r\n```\r\n\r\nAs you can see the `input` and `output` variables both have the correct type inferred. The `client.test.mutate` input also has the correct type inferred, however if you look at the return type of the `client.test.mutate` it is :\r\n\r\n```ts\r\n{\r\n [x: string]: never;\r\n [x: number]: never;\r\n}\r\n```\r\n\r\nIf I were to remove the .catchall from the zod object (for e.g. .passthrough) it will work, but I lose the ability to add extra properties in TS.\r\n\r\nThis could be a zod issue (if so please let me know and I'll open this issue there instead). But as the type inference works in all cases except in the return type of the trpc client I thought it may be something to do with trpc instead.\n\n### Link to reproduction\n\nhttps://github.com/TimoGlastra/trpc-zod-issue\n\n### To reproduce\n\nClone the repo above, run `yarn install` then run `yarn tsc`. This will build the d.ts file in `build/index.d.ts` and you can see the output as described above.\n\n### Additional information\n\nWould be willing to contribute a PR but wouldn't know where to start or whether this is solveable.\n\n### 👨👧👦 Contributing\n\n- [X] 🙋♂️ Yes, I'd be down to file a PR fixing this bug!",[],3320,"bug: output type incorrectly inferred when compiling typescript for client when using zod .catchall()","2023-06-08T00:05:38Z","https://github.com/trpc/trpc/issues/3320",0.7052751,{"description":3109,"labels":3110,"number":3114,"owner":3021,"repository":3021,"state":3037,"title":3115,"updated_at":3116,"url":3117,"score":3118},"### Provide environment information\n\nSystem:\n OS: Windows 11 10.0.26100\n CPU: (16) x64 11th Gen Intel(R) Core(TM) i7-11700K @ 3.60GHz\n Memory: 18.28 GB / 31.87 GB\nBinaries:\n Node: 22.11.0 - C:\\Program Files\\nodejs\\node.EXE\n npm: 11.3.0 - C:\\Program Files\\nodejs\\npm.CMD\n pnpm: 8.9.2 - ~\\AppData\\Local\\pnpm\\pnpm.EXE\n bun: 1.2.16 - ~\\.bun\\bin\\bun.EXE\nBrowsers:\n Edge: Chromium (135.0.3179.66)\n Internet Explorer: 11.0.26100.1882\nnpmPackages (server):\n @trpc/server: ^11.4.2 => 11.4.2 \n typescript: ^5.8.3 => 5.8.3\nnpmPackages (client):\n @trpc/client: ^11.4.2 => 11.4.2 \n @trpc/server: ^11.4.2 => 11.4.2 \n typescript: ^5.8.3 => 5.8.3\n\n### Describe the bug\n\nAs discussed with a maintainer in **Discussion #6829**, I'm opening this issue to report a type-leakage bug.\n\nWhen a server-only type (like an instance of a `pino` logger) is included in the tRPC `Context`, its type definition leaks to the client when importing the `AppRouter`. This causes TypeScript compilation to fail on the client-side because it cannot resolve the server-only dependency.\n\nThe expected behavior is that the client-side type inference for `AppRouter` should not be affected by non-serializable, server-only objects within the `Context`. The maintainer in the discussion confirmed that the context is not supposed to leak, which suggests this is unintended behavior.\n\nThe primary errors observed on the client are:\n1. A type portability error `ts(2742)` on the `createTRPCClient` call, explicitly mentioning the server's `pino` module.\n2. A type constraint failure on the `AppRouter` generic, indicating a module path mismatch between the server's and client's versions of `@trpc/server` due to the polluted context type. (Not visible in repro repo)\n\n### Link to reproduction\n\nhttps://github.com/matvejs16/trpc-type-leak\n\n### To reproduce\n\n1. Clone the reproduction repository: `git clone https://github.com/matvejs16/trpc-type-leak.git`\n2. Navigate into the project directory: `cd trpc-type-leak`\n3. Install all dependencies in `client` and `server`: `npm install`\n4. Open the project in a TypeScript-aware editor like VS Code.\n5. Navigate to the file: `client/src/tRPC.ts`.\n6. You will immediately see TypeScript errors highlighted on the `client` variable declaration, demonstrating the type-leak issue. No need to run the application, as this is a compile-time/type-checking error.\n\n### Additional information\n\nThe core of the issue seems to be that the inferred type of `AppRouter` includes the full, non-portable type definition of the `Context` object. In the reproduction, the `Context` contains a `requestLogger` property typed as `pino.Logger`. Because the `client` package does not have `pino` as a dependency, TypeScript rightfully fails to resolve the type.\n\nThis issue is likely to affect anyone working in a monorepo who attempts to integrate common server-side tools like loggers, database clients, or other class-based services directly into the tRPC context.\n\n### 👨👧👦 Contributing\n\n- [ ] 🙋♂️ Yes, I'd be down to file a PR fixing this bug!",[3111],{"name":3112,"color":3113},"🐛 bug: unconfirmed","e99695",6830,"bug: Server-only types in Context leak to the client, causing type portability errors","2025-06-24T10:26:28Z","https://github.com/trpc/trpc/issues/6830",0.706787,["Reactive",3120],{},["Set"],["ShallowReactive",3123],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$fXJivqNhLxYpw0TlReGNeDUfQdnaMiJ31k0ML2oWBAI4":-1},"/trpc/v10-playground/35"]