Migrating from v11
Serve v11 clients from the new router with createV11Handler, run the codemod, then move the clients.
Move the server first, so you can deploy before every client (a mobile app in the stores, a tab left open) updates. Then move the clients to @trpc12/trpc/client and drop the old endpoint:
- Serve v11 clients from the new router.
createV11Handlerfrom@trpc12/trpc/interopspeaks every v11 link on the endpoint they already call, next to the v12 handler (Serving v11 clients). - Run the codemod.
npx @trpc12/upgrade srcrewrites what has one v12 form and lists the rest asfile:line:columnsteps (The codemod). - Move the clients. Your own v11 links keep working in a v12 chain with
fromV11Linkuntil you rewrite them (v11 links). - Drop the old endpoint once no v11 client calls it.
API changes maps each v11 API to its v12 form.
The examples/v11-migration app follows these steps. Its v11 clients (batching, SSE and WebSocket subscriptions, superjson, TanStack Query) call the new server through createV11Handler. Its v12 client keeps a custom v11 link through fromV11Link. Its smoke runs the codemod on a copy of the v11 app and checks every step it prints.
Pages under Migrating from v11
- Serving v11 clientscreateV11Handler serves the new router to @trpc/client 11 apps on the endpoint they already call, in v11's wire format and error shape.
- The codemod@trpc12/upgrade rewrites v11 imports, names, links and transformers to v12, keeps your formatting, and lists what is left as file:line:column steps.
- v11 linksfromV11Link runs a v11 TRPCLink in a v12 chain, so you can move links one at a time, and what a rewritten link looks like.
- API changesEach v11 API next to its v12 form: init, errors, transformers, handlers, adapters, clients, links, callers and subscriptions.