www/docs/server/validators.md (3)

8-8: Tighten phrasing and hyphenation

Small clarity/style tweak and hyphenation:

• “first class support” → “first-class support”
• Consider splitting the long sentence for readability.

- 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.
+ tRPC procedures may define validation logic for their input and/or output. 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.

---

172-172: Specify the version: “Standard Schema v1”

Since the code targets v1, make it explicit to reduce ambiguity.

- including any library conforming to [Standard Schema](https://standardschema.dev).
+ including any library conforming to [Standard Schema v1](https://standardschema.dev).

---

498-498: Tone/style: avoid “Feel free to” and clarify

Consider a more direct tone and minor rewording:

- 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.
+ Conforming to [Standard Schema](https://standardschema.dev) is recommended. In some cases, we may accept a PR to add a new supported interface. You can open an issue to discuss your use case.

packages/tests/server/validators.test.ts (1)

938-942: Nice addition: direct branded scalar route covered

This validates Standard Schema-based inference for scalar inputs. Consider also asserting router-level types for top to mirror the num checks:

   type RouterInput = inferRouterInputs<typeof router>;
   type RouterOutput = inferRouterOutputs<typeof router>;
 
   type AccountIdInput = RouterInput['num']['accountId'];
   //     ^?
   type AccountIdOutput = RouterOutput['num']['accountId'];
   //    ^?
 
   expectTypeOf<AccountIdInput>().toEqualTypeOf<Types['input']>();
   expectTypeOf<AccountIdOutput>().toEqualTypeOf<Types['output']>();
+
+  // Additional coverage for the scalar route:
+  type TopInput = RouterInput['top'];
+  //    ^?
+  type TopOutput = RouterOutput['top'];
+  //   ^?
+  expectTypeOf<TopInput>().toEqualTypeOf<Types['input']>();
+  expectTypeOf<TopOutput>().toEqualTypeOf<Types['output']>();

This strengthens the guarantee that the public API reflects the Standard Schema types for both object-wrapped and direct scalar forms.

packages/server/src/unstable-core-do-not-import/parser.ts (1)

65-81: Prefer Standard Schema in inferParser: correct precedence

Good change. This ensures dual-interface parsers (e.g., Zod v4) infer via Standard Schema first, avoiding stale or incorrect internals.

Consider adding a brief doc comment to lock in the intent and reduce future regressions:

 export type inferParser<TParser extends Parser> =
+  /**
+   * Precedence:
+   * 1) Standard Schema v1 (canonical input/output)
+   * 2) Parsers exposing explicit input/output internals
+   * 3) Parsers with single in/out type (custom fn, myzod, scale, superstruct, yup)
+   */
   TParser extends ParserStandardSchemaEsque<infer $TIn, infer $TOut>
     ? { in: $TIn; out: $TOut }
     : TParser extends ParserWithInputOutput<infer $TIn, infer $TOut>
       ? { in: $TIn; out: $TOut }
       : TParser extends ParserWithoutInput<infer $InOut>
         ? { in: $InOut; out: $InOut }
         : never;

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

packages/server/src/unstable-core-do-not-import/parser.ts (1)

67-70: Including StandardSchemaV1 in Parser unblocks the first branch of inferParser

By adding StandardSchemaV1 to the Parser union, the Standard Schema branch in inferParser becomes reachable and preferred. This also addresses the prior “unreachable branch” concern raised earlier.

packages/server/src/unstable-core-do-not-import/parser.ts (3)

72-88: Optional: remove the generic constraint to decouple inference from the Parser union

inferParser now works because Parser includes StandardSchemaV1. To make this robust against future changes to Parser (and to allow inference on any Standard Schema-implementing value even if it isn’t typed as Parser), consider dropping the extends Parser constraint. This keeps the precedence logic self-contained and avoids reintroducing the “unreachable branch” class of issues if Parser is refactored later.

Proposed minimal change:

-export type inferParser<TParser extends Parser> =
+export type inferParser<TParser> =
   TParser extends StandardSchemaV1<infer $TIn, infer $TOut>
     ? {
         in: $TIn;
         out: $TOut;
       }
     : TParser extends ParserWithInputOutput<infer $TIn, infer $TOut>
       ? {
           in: $TIn;
           out: $TOut;
         }
       : TParser extends ParserWithoutInput<infer $InOut>
         ? {
             in: $InOut;
             out: $InOut;
           }
         : never;

---

49-51: Nit: capitalize and hyphenate “Standard Schema” in the deprecation note

For consistency with the docs and naming elsewhere, prefer “non-Standard Schema”.

 /**
- * @deprecated we can drop support for non standard schema parsers in the next major version
+ * @deprecated We can drop support for non-Standard Schema parsers in the next major version
  */

---

59-61: Nit: same capitalization/hyphenation fix here

 /**
- * @deprecated we can drop support for non standard schema parsers in the next major version
+ * @deprecated We can drop support for non-Standard Schema parsers in the next major version
  */

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.