`, `pnpm build` works again.\r\n\r\n_No response_\r\n\r\n### 👨👧👦 Contributing\r\n\r\n- [ ] 🙋♂️ Yes, I'd be down to file a PR fixing this bug!",[3044],{"name":3045,"color":3046},"🐛 bug: unconfirmed","e99695",6121,"bug: nextjs build got \"prerender error\" when using prefetch","2025-03-20T15:42:38Z","https://github.com/trpc/trpc/issues/6121",0.80174214,{"description":3053,"labels":3054,"number":3058,"owner":3027,"repository":3027,"state":3028,"title":3059,"updated_at":3060,"url":3061,"score":3062},"_Originally posted by @KATT in https://github.com/trpc/trpc/discussions/1936#discussioncomment-2818345_\r\n\r\nIf we go down this route what we're really talking about is straying away from JSON as the defacto mode of transport. If we do this we should also have support for some sort of binary format when doing `POST`s that could take the compression further and let us have something else than `content-type: application/json`.\r\n\r\nFurthermore, I think the server should be able to receive different types of request types and be informed on what to do. I have thought about this a bit before in the context of transformers, so outlining below.\r\n\r\n## Some ideas for communicating transformers/serializer\r\n\r\n> Rough ideas below, I think best by writing code, but don't see any of this as a final design.\r\n\r\n### `contentType`-param\r\n\r\nGoals:\r\n\r\n- Allow for multiple content-types\r\n- Allow for deserializing from a `Response` with a `body`\r\n- Allow for serializing into a `Fetch.body`\r\n- Allow for serializing into a string for query params\r\n\r\n**When creating a server:**\r\n\r\n```ts\r\nimport { initTRPC } from '@trpc/server';\r\nimport { jsonContentType, createContentType } from '@trpc/server/content-type';\r\n\r\n// JSON crush could be a community plugin that looks something like this:\r\nimport jsoncrush from 'jsoncrush';\r\nconst crush = createContentType({\r\n key: 'crush',\r\n contentType: 'application/json',\r\n // a smarter content type would use something that could be streamed, i.e ReadableStream from `Response`\r\n // used for `POST`:\r\n fromResponse: async (res) => jsoncrush.uncrush(await res.text()),\r\n fromString: (str) => jsoncrush.uncrush(str),\r\n toBody: data => jsoncrush.crush(data), // this could allow for the types that the `Fetch API` allows - ArrayBuffer, string, [...]\r\n // used for `GET`\r\n toString: data => jsoncrush.data(data),\r\n})\r\n\r\nconst trpc = initTRPC({\r\n contentTypes: [\r\n jsonContentType,\r\n crush,\r\n }\r\n});\r\n```\r\n\r\n**HTTP level**\r\n\r\n```\r\n// inform server that we are sending `crush` content\r\nGET http://localhost?content=crush&input=[...]\r\nGET http://localhost?content=json&input=[...]\r\n\r\nPOST http://localhost?content=crush\r\ncontent-type: \"application/json\"\r\n// [..]\r\n```\r\n\r\n### Similarly, `transformer`-param could be used\r\n\r\n```ts\r\nimport { initTRPC } from '@trpc/server';\r\nimport { defaultTransform } from '@trpc/server/transform';\r\n// JSON crush could be a community plugin\r\nimport { crush } from 'trpc-json-crush';\r\n\r\nconst trpc = initTRPC({\r\n transforms: [\r\n defaultTransform, // our \"no-op\" trnasform\r\n { key: \"superjson\", value: superjson },\r\n ],\r\n});\r\n```\r\n\r\n### The client story\r\n\r\nMaybe only needs to allow for one content type.\r\n\r\n```ts\r\nimport { crush } from \"~/shared/contentType\"\r\n\r\nconst client = createTRPCClient({\r\n links: [ /* ... */ ],\r\n contentType: crush,\r\n});\r\n\r\n```\n\n\u003Csub>[TRP-67](https://linear.app/trpc/issue/TRP-67/support-for-additional-content-types)\u003C/sub>",[3055],{"name":3056,"color":3057},"💡 ideas","bfdadc",1937,"Support for additional `Content-Type`s","2025-03-20T15:41:28Z","https://github.com/trpc/trpc/issues/1937",0.81032544,{"description":3064,"labels":3065,"number":3069,"owner":3027,"repository":3027,"state":3070,"title":3071,"updated_at":3072,"url":3073,"score":3074},"### Provide environment information\r\n\r\n System:\r\n OS: macOS 14.2.1\r\n CPU: (8) arm64 Apple M1 Pro\r\n Memory: 181.14 MB / 16.00 GB\r\n Shell: 5.9 - /bin/zsh\r\n Binaries:\r\n Node: 20.11.0 - ~/.nvm/versions/node/v20.11.0/bin/node\r\n Yarn: 1.22.21 - ~/.nvm/versions/node/v20.11.0/bin/yarn\r\n npm: 10.2.4 - ~/.nvm/versions/node/v20.11.0/bin/npm\r\n pnpm: 8.14.1 - ~/.nvm/versions/node/v20.11.0/bin/pnpm\r\n Watchman: 2023.12.04.00 - /opt/homebrew/bin/watchman\r\n Browsers:\r\n Chrome: 120.0.6099.216\r\n Safari: 17.2.1\r\n\r\n### Describe the bug\r\n\r\n`.listen()` method should return a Promise object as:\r\n1) if the port is static then we don't need a promise wrapper\r\n2) if the port is dynamic then we need to wrap to a promise and wait for a `listening` event\r\n\r\n### Link to reproduction\r\n\r\nhttps://stackblitz.com/edit/stackblitz-starters-79vedc\r\n\r\n### To reproduce\r\n\r\nWe can see in the console that the port is undefined\r\n\r\n### Additional information\r\n\r\n_No response_\r\n\r\n### 👨👧👦 Contributing\r\n\r\n- [ ] 🙋♂️ Yes, I'd be down to file a PR fixing this bug!",[3066],{"name":3067,"color":3068},"@trpc/server","9BE78E",5345,"closed","feat: return `Promise` in `.listen()`","2025-03-20T15:42:12Z","https://github.com/trpc/trpc/issues/5345",0.7609044,{"description":3076,"labels":3077,"number":3084,"owner":3027,"repository":3027,"state":3070,"title":3085,"updated_at":3086,"url":3087,"score":3088},"### Describe the feature you'd like to request\r\n\r\nThese two should have the same cache key:\r\n\r\n```ts\r\ntrpc.foo.useQuery(undefined, { /* .. */ })\r\ntrpc.foo.useQuery()\r\n```\r\n\r\nOr like\r\n\r\n```ts\r\nuseContext().foo.fetch(undefined)\r\nuseContext().foo.fetch()\r\n```\r\n\r\n### 👨👧👦 Contributing\r\n\r\n* [X] 🙋♂️ Yes, I'd be down to file a PR implementing this feature!\r\n\r\n\u003Csub>From [SyncLinear.com](https://synclinear.com) | [T-83](https://linear.app/trpc/issue/T-83/featreact-query-normalize-hydration-for-undefineds)\u003C/sub>",[3078,3081],{"name":3079,"color":3080},"👻 invalid","e4e669",{"name":3082,"color":3083},"@trpc/react-query","375E6E",4442,"[T-83] feat(`react-query`): normalize cache keys for `undefined`s","2025-03-20T15:41:40Z","https://github.com/trpc/trpc/issues/4442",0.77532834,{"description":3090,"labels":3091,"number":3093,"owner":3027,"repository":3027,"state":3070,"title":3094,"updated_at":3095,"url":3096,"score":3097},"### Provide environment information\n\n```\n System:\n OS: Linux 6.12 Arch Linux\n CPU: (16) x64 AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics\n Memory: 7.71 GB / 30.06 GB\n Container: Yes\n Shell: 5.9 - /bin/zsh\n Binaries:\n Node: 22.2.0 - ~/.nvm/versions/node/v22.2.0/bin/node **(also tried 23.6.1)**\n Yarn: 1.22.22 - ~/.nvm/versions/node/v22.2.0/bin/yarn\n npm: 10.7.0 - ~/.nvm/versions/node/v22.2.0/bin/npm\n bun: 1.0.3 - ~/.bun/bin/bun\n npmPackages:\n @tanstack/react-query: ^5.64.2 => 5.64.2 \n @trpc/client: 11.0.0-rc.718 => 11.0.0-rc.718+2018e3914 \n @trpc/react-query: 11.0.0-rc.718 => 11.0.0-rc.718+2018e3914 \n @trpc/server: 11.0.0-rc.718 => 11.0.0-rc.718+2018e3914 \n react: ^18.3.1 => 18.3.1 \n typescript: 5.7.2 => 5.7.2\n```\n\n### Describe the bug\n\nWhen using http2, the response body is always empty when the method is POST. I was able to trace the problem and discovered that the reason for this is that the request is being aborted in response to this event:\n\nhttps://github.com/trpc/trpc/blob/776d07336bddd01ac2ad02da0360fb71aa734471/packages/server/src/adapters/node-http/incomingMessageToRequest.ts#L147\n\nIf I don't pass the abort signal in the stream pipe, it is able to write to the stream without any issue and everything works. Here is where I made that change:\n\nhttps://github.com/trpc/trpc/blob/776d07336bddd01ac2ad02da0360fb71aa734471/packages/server/src/adapters/node-http/writeResponse.ts#L50-L52\n\nI'll be honest, it doesn't make sense to me why the response close event fires and yet I can still write it to it just fine. I'm also not sure how to deal with this situation without breaking proper abort handling elsewhere.\n\n### Link to reproduction\n\nhttps://github.com/cseickel/trpc-http2-post-example\n\n### To reproduce\n\nUnfortunately it does not run in stakblitz for me, maybe because it requires an ssl connection. You can clone the linked repo and follow the readme.\n\nhttps://github.com/cseickel/trpc-http2-post-example\n\n### Additional information\n\nI understand that no where does the project explicitly state that HTTP2 is supported, but I'm hoping it is within scope. The reason I want to use HTTP2 is that it is really important for using the SSE subscription feature. The reason for this is that each subscription opens a new connection, and with HTTP/1 the browser will not open more than 6 connections of any type to one server. This limit applies across multiple tabs as well, so it is really hard to stay under that limit. \n\nHTTP/2 removes this limit and makes SSE feasible.\n\nThank you for the awesome project!\n\n\n### 👨👧👦 Contributing\n\n- [x] 🙋♂️ Yes, I'd be down to file a PR fixing this bug!",[3092],{"name":3067,"color":3068},6432,"bug: Response not written to POST requests on HTTP2 connection","2025-02-07T12:02:56Z","https://github.com/trpc/trpc/issues/6432",0.77891105,{"description":3099,"labels":3100,"number":3101,"owner":3027,"repository":3027,"state":3070,"title":3102,"updated_at":3103,"url":3104,"score":3105},"### Provide environment information\r\n\r\n```\r\n System:\r\n OS: macOS 13.4.1\r\n CPU: (8) arm64 Apple M1\r\n Memory: 223.42 MB / 16.00 GB\r\n Shell: 5.9 - /bin/zsh\r\n Binaries:\r\n Node: 18.16.0 - ~/.nvm/versions/node/v18.16.0/bin/node\r\n Yarn: 1.22.19 - ~/.nvm/versions/node/v18.16.0/bin/yarn\r\n npm: 9.8.1 - ~/.nvm/versions/node/v18.16.0/bin/npm\r\n pnpm: 8.6.6 - ~/.nvm/versions/node/v18.16.0/bin/pnpm\r\n Browsers:\r\n Brave Browser: 115.1.56.14\r\n Safari: 16.5.2\r\n npmPackages:\r\n @tanstack/react-query: ^4.18.0 => 4.32.1 \r\n @trpc/client: ^10.36.0 => 10.36.0 \r\n @trpc/next: ^10.36.0 => 10.36.0 \r\n @trpc/react-query: ^10.36.0 => 10.36.0 \r\n @trpc/server: ^10.36.0 => 10.36.0 \r\n next: ^13.4.8 => 13.4.12 \r\n react: 18.2.0 => 18.2.0 \r\n typescript: 5.1.3 => 5.1.3 \r\n```\r\n\r\n### Describe the bug\r\n\r\nWhile using [https://github.com/trpc/trpc/tree/main/examples/next-prisma-todomvc](next-prisma-todomvc) reproduction everything seems to be working fine, however, when I do first request httpUtils gets this error:\r\n\r\n```\r\n \u003C\u003C query #1 user.all {\r\n input: undefined,\r\n result: TRPCClientError: Unexpected token \u003C in JSON at position 0\r\n at TRPCClientError.from (file:///Volumes/DEV/ulobo/node_modules/@trpc/client/dist/TRPCClientError-fef6cf44.mjs:26:16)\r\n at file:///Volumes/DEV/ulobo/node_modules/@trpc/client/dist/httpUtils-ad76b802.mjs:125:36\r\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {\r\n meta: { response: [Response] },\r\n shape: undefined,\r\n data: undefined,\r\n [cause]: SyntaxError: Unexpected token \u003C in JSON at position 0\r\n at JSON.parse (\u003Canonymous>)\r\n at parseJSONFromBytes (node:internal/deps/undici/undici:6571:19)\r\n at successSteps (node:internal/deps/undici/undici:6545:27)\r\n at node:internal/deps/undici/undici:1211:60\r\n at node:internal/process/task_queues:140:7\r\n at AsyncResource.runInAsyncScope (node:async_hooks:203:9)\r\n at AsyncResource.runMicrotask (node:internal/process/task_queues:137:8)\r\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\r\n },\r\n elapsedMs: 61\r\n}\r\nTRPCClientError: Unexpected token \u003C in JSON at position 0\r\n at TRPCClientError.from (file:///Volumes/DEV/ulobo/node_modules/@trpc/client/dist/TRPCClientError-fef6cf44.mjs:26:16)\r\n at file:///Volumes/DEV/ulobo/node_modules/@trpc/client/dist/httpUtils-ad76b802.mjs:125:36\r\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {\r\n meta: {\r\n response: Response {\r\n [Symbol(realm)]: null,\r\n [Symbol(state)]: [Object],\r\n [Symbol(headers)]: [HeadersList]\r\n }\r\n },\r\n shape: undefined,\r\n data: undefined,\r\n [cause]: SyntaxError: Unexpected token \u003C in JSON at position 0\r\n at JSON.parse (\u003Canonymous>)\r\n at parseJSONFromBytes (node:internal/deps/undici/undici:6571:19)\r\n at successSteps (node:internal/deps/undici/undici:6545:27)\r\n at node:internal/deps/undici/undici:1211:60\r\n at node:internal/process/task_queues:140:7\r\n at AsyncResource.runInAsyncScope (node:async_hooks:203:9)\r\n at AsyncResource.runMicrotask (node:internal/process/task_queues:137:8)\r\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\r\n}\r\n```\r\n\r\n\r\n\r\n### Link to reproduction\r\n\r\nhttps://github.com/porydzaj/trpc-404-httputils\r\n\r\n### To reproduce\r\n\r\nRun first fetch at index with utils/trpc\r\n\r\n### Additional information\r\n\r\n_No response_\r\n\r\n### 👨👧👦 Contributing\r\n\r\n- [ ] 🙋♂️ Yes, I'd be down to file a PR fixing this bug!",[],4671,"bug: Unexpected token \u003C in JSON at position 0","2025-03-20T15:41:49Z","https://github.com/trpc/trpc/issues/4671",0.7830217,{"description":3107,"labels":3108,"number":3109,"owner":3027,"repository":3027,"state":3070,"title":3110,"updated_at":3111,"url":3112,"score":3113},"Hey, folks!\r\n\r\nWe ran into a hiccup with trying to dynamically type the data that comes back from our endpoint.\r\n\r\nImagine an identity endpoint that can return either a string or a number:\r\n```\r\n// I recognize that you probably wouldn't do actually want to do this\r\n// This is only an example to setup for our more complex real world example\r\n\r\nconst router = createRouter().query(\"foo\", {\r\n input: z.enum([\"string\", \"number\"]),\r\n\tresolve: async ({input}) => {\r\n\t\tconst pickEm = {\r\n\t\t\tstring \"test\",\r\n\t\t\tnumber: 42\r\n\t\t}\r\n\r\n\t\treturn pickEm[input]\r\n\t}\r\n})\r\n\r\n```\r\nNow, when we go to use this on the frontend:\r\n```\r\nconst query = trpc.useQuery([\"foo\", \"string\"])\r\nquery.data // Inferred type is number | string | undefined\r\n// I would love for this hook have an inferred type of string\r\n\r\n```\r\n\r\n```\r\nconst query = trpc.useQuery([\"foo\", \"number\"])\r\nquery.data // Inferred type is number | string | undefined\r\n// I would love for this hook have an inferred type of number\r\n```\r\n\r\nThat's my simple, silly example to demonstrate the idea of what we're after. \r\nIn the real world, what we are running into is this:\r\n```\r\n// trials/get is an endpoint that takes inputs for Prisma includes or selects for the Trial model\r\nconst query = trpc.useQuery([\"trials/get\", { select: { judgeName: true } } ])\r\nquery.data // Has no idea about the select, simply types for the whole Trial model\r\n```\r\n\r\nAnd here is our custom hook that we hacked together to resolve our problem.\r\n```\r\n\r\nexport const useTrial = \u003CT extends Prisma.TrialSelect>({\r\n\ttrialId,\r\n\tselect\r\n}: {\r\n\ttrialId: string\r\n\tselect: Prisma.Subset\u003CT, Prisma.TrialSelect>\r\n}) => {\r\n\ttype DataPayload = Prisma.TrialGetPayload\u003C{ select: typeof select }>\r\n\r\n\tconst query = trpc.useQuery([\"trials/get\", { id: trialId, select }])\r\n\r\n\tconst queryDataTypeFix = query.data as Prisma.TrialSelect\r\n\r\n\t// Fix the data with itself but typed as what we want\r\n\tquery.data = queryDataTypeFix\r\n\r\n\treturn query as\r\n\t\t| Omit\u003Ctypeof query, \"data\"> & {\r\n\t\t\t\tdata: DataPayload\r\n\t\t }\r\n}\r\n```\r\n\r\nThis seems to work well enough to get the types right. But I was surprised there wasn't a more tRPC-ish way (that we could figure out).\r\n\r\n100% am willing to contribute if there is a way we think we can do this - although I can't say I'll be too useful actually making the types happen. The TS you guys have drawn up is pretty opaque to me. 🙃 \r\n\r\nI know with v10 coming, we could be allowed to make some major change if needed to make this reality.\r\n\r\ntRPC for life, yo! Keep it up!",[],2137,"Dynamically type the data result of a hook according to inputs","2022-07-11T05:27:46Z","https://github.com/trpc/trpc/issues/2137",0.80341923,{"description":3115,"labels":3116,"number":3121,"owner":3027,"repository":3027,"state":3070,"title":3122,"updated_at":3123,"url":3124,"score":3125},"### Provide environment information\n\nSystem:\n OS: macOS 15.0.1\n CPU: (8) arm64 Apple M1 Pro\n Memory: 101.39 MB / 16.00 GB\n Shell: 5.9 - /bin/zsh\n Binaries:\n Node: 20.18.1 - ~/.nvm/versions/node/v20.18.1/bin/node\n Yarn: 4.6.0 - ~/.nvm/versions/node/v20.18.1/bin/yarn\n npm: 10.8.2 - ~/.nvm/versions/node/v20.18.1/bin/npm\n bun: 1.2.0 - ~/.bun/bin/bun\n Watchman: 2024.11.04.00 - /opt/homebrew/bin/watchman\n Browsers:\n Chrome: 133.0.6943.127\n Safari: 18.0.1\n npmPackages:\n @trpc/client: ^11.0.0-rc.791 => 11.0.0-rc.791+4eda4d50f\n @trpc/server: ^11.0.0-rc.791 => 11.0.0-rc.791+4eda4d50f\n typescript: ^5.7.3 => 5.7.3\n\n### Describe the bug\n\nWhen using TRPC v11 with the Express adapter, the input received on server (serialized by supersjon on client) can't be correctly deserialized by superjson (eg: Date remains string). By diving into superjson's code, it seems this equality is not met https://github.com/flightcontrolhq/superjson/blob/main/src/is.ts#L16. When creating the exact same input into the transformer (on server side), it works as intended, example : \n```ts\ntransformer: {\n input: {\n serialize: superjson.serialize,\n deserialize: (data: any) => {\n // Artificial input copy\n const foo = {\n \"json\": {\n \"date\": \"2025-02-21T09:33:09.469Z\"\n },\n \"meta\": {\n \"values\": {\n \"date\": [\n \"Date\"\n ]\n }\n }\n }\n\n // Here, date will be transformed into date\n console.log(superjson.deserialize(foo));\n\n // Here, date will not be transformed into date\n return superjson.deserialize(data);\n },\n },\n output: {\n serialize: superjson.serialize,\n deserialize: superjson.deserialize,\n },\n },\n```\n\nIt seems this behaviour appeared in 11.0.0-rc.362, it worked fine on 11.0.0-rc.361 and below.\n\n### Link to reproduction\n\nhttps://github.com/emileNetter/trpc-superjson-repro\n\n### To reproduce\n\n```bash\ncorepack enable\nyarn install\nyarn test\n```\n\nThe test fails because the date can't be converted to Date and zod schema throws an error.\n\n### Additional information\n\n_No response_\n\n### 👨👧👦 Contributing\n\n- [ ] 🙋♂️ Yes, I'd be down to file a PR fixing this bug!",[3117,3118],{"name":3045,"color":3046},{"name":3119,"color":3120},"⏳ close if no activity","d4c5f9",6540,"bug: input can't be deserialized by superjson with express adapter","2025-03-18T00:08:02Z","https://github.com/trpc/trpc/issues/6540",0.80717963,["Reactive",3127],{},["Set"],["ShallowReactive",3130],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$fq7z3UgwYBSSRNxE4SgnyhjBnVPIpQqAWMaUQNfLJl2Y":-1},"/trpc/trpc-openapi/431"]