tRPC v10 transformer removal: handling Date, Map, Set, and BigInt serialization without superjson defaults

Serialization boundary after upgrading from v9

tRPC v10 removed the implicit superjson transformer that v9 applied by default. Applications upgrading without explicit transformer configuration now send Date, Map, Set, and BigInt values as plain JSON objects or trigger runtime serialization errors, even though TypeScript types continue to compile.

Constraint: wire-format compatibility across client and server

The transformer sits between client links and server procedures, so both ends must agree on the same serialization strategy. A mismatch produces payloads that React Query caches under different keys or that the server cannot deserialize into the expected procedure input types.

Open decision: first-party streaming and FormData transformer

The tRPC maintainers have not yet shipped a first-party transformer for FormData and streaming payloads, leaving teams to choose between community packages, custom implementations, or avoiding those types entirely in procedure signatures.

What is the recommended migration path for a v9 codebase that relied on automatic Date and Map serialization but cannot adopt superjson due to bundle-size constraints? Should procedure input/output schemas be rewritten to use primitive-only types, or is a minimal custom transformer the only viable option? How can a team verify that client and server transformer configurations remain in sync across deployments without runtime payload inspection?