fix: prefer Standard Schema for input/output type inference

dzhu · dzhu · commit bbad5c7b1770 · 2025-08-10T22:01:47.000-06:00
Since it is the new and standard thing, we should use Standard Schema to extract input and output types whenever the schema implements it. Fixes #6887
diff --git a/packages/server/src/unstable-core-do-not-import/parser.ts b/packages/server/src/unstable-core-do-not-import/parser.ts
@@ -62,17 +62,22 @@ export type ParserWithInputOutput<TInput, TParsedInput> =
 export type Parser = ParserWithInputOutput<any, any> | ParserWithoutInput<any>;
 
 export type inferParser<TParser extends Parser> =
-  TParser extends ParserWithInputOutput<infer $TIn, infer $TOut>
+  TParser extends ParserStandardSchemaEsque<infer $TIn, infer $TOut>
     ? {
         in: $TIn;
         out: $TOut;
       }
-    : TParser extends ParserWithoutInput<infer $InOut>
+    : TParser extends ParserWithInputOutput<infer $TIn, infer $TOut>
       ? {
-          in: $InOut;
-          out: $InOut;
+          in: $TIn;
+          out: $TOut;
         }
-      : never;
+      : TParser extends ParserWithoutInput<infer $InOut>
+        ? {
+            in: $InOut;
+            out: $InOut;
+          }
+        : never;
 
 export type ParseFn<TType> = (value: unknown) => Promise<TType> | TType;
 
diff --git a/packages/tests/server/validators.test.ts b/packages/tests/server/validators.test.ts
@@ -935,6 +935,11 @@ test('zod4 branded types', () => {
         expectTypeOf(opts.input.accountId).toEqualTypeOf<Types['output']>();
         return opts.input;
       }),
+
+    top: t.procedure.input(AccountId).query((opts) => {
+      expectTypeOf(opts.input).toEqualTypeOf<Types['output']>();
+      return opts.input;
+    }),
   });
 
   type RouterInput = inferRouterInputs<typeof router>;
diff --git a/www/docs/server/validators.md b/www/docs/server/validators.md
@@ -5,7 +5,7 @@ sidebar_label: Input & Output Validators
 slug: /server/validators
 ---
 
-tRPC procedures may define validation logic for their input and/or output, and validators are also used to infer the types of inputs and outputs. We have first class support for many popular validators, and you can [integrate validators](#contributing-your-own-validator-library) which we don't directly support.
+tRPC procedures may define validation logic for their input and/or output, and validators are also used to infer the types of inputs and outputs (using the [Standard Schema](https://standardschema.dev) interface if available, or custom interfaces for supported validators if not). We have first class support for many popular validators, and you can [integrate validators](#contributing-your-own-validator-library) which we don't directly support.
 
 ## Input Validators
 
@@ -169,7 +169,7 @@ export type AppRouter = typeof appRouter;
 
 ## Library integrations
 
-tRPC works out of the box with a number of popular validation and parsing libraries, including any library conforming to [standard-schema](https://standardschema.dev). The below are some examples of usage with validators which we officially maintain support for.
+tRPC works out of the box with a number of popular validation and parsing libraries, including any library conforming to [Standard Schema](https://standardschema.dev). The below are some examples of usage with validators which we officially maintain support for.
 
 ### With [Zod](https://github.com/colinhacks/zod)
 
@@ -495,4 +495,4 @@ export type AppRouter = typeof appRouter;
 
 If you work on a validator library which supports tRPC usage, please feel free to open a PR for this page with equivalent usage to the other examples here, and a link to your docs.
 
-Integration with tRPC in most cases is as simple as meeting one of several existing type interfaces. Conforming to [standard-schema](https://standardschema.dev) is recommended, but in some cases we may accept a PR to add a new supported interface. Feel free to open an issue for discussion. You can check the existing supported interfaces and functions for parsing/validation [in code](https://github.com/trpc/trpc/blob/main/packages/server/src/unstable-core-do-not-import/parser.ts).
+Integration with tRPC in most cases is as simple as meeting one of several existing type interfaces. Conforming to [Standard Schema](https://standardschema.dev) is recommended, but in some cases we may accept a PR to add a new supported interface. Feel free to open an issue for discussion. You can check the existing supported interfaces and functions for parsing/validation [in code](https://github.com/trpc/trpc/blob/main/packages/server/src/unstable-core-do-not-import/parser.ts).
