If you created your client before v0.13.0, this is the entire migration. It is mechanical: constructor options became a one-element links array. Ten minutes, no behavior changes beyond batching (if you opt into it).
Before and after
// BEFORE (pre-0.13.0)
const api = createClient<Types>({ url: "http://localhost:8000" })// AFTER (v0.13.0)
import { createClient, httpBatchLink } from "@pyrpc/client"
const api = createClient<Types>({
links: [httpBatchLink({ url: "http://localhost:8000" })],
})Prefer strictly one-request-per-call? Use httpLink instead of httpBatchLink. Everything else about your client, procedure calls, types, error shapes, is unchanged.
Framework adapters
Adapters re-export the links, so keep imports canonical to your adapter package:
// React / Next.js / Vue / Svelte, same shape everywhere
import { createReactClient, httpBatchLink } from "@pyrpc/react"
export const api = createReactClient<Types>({
links: [httpBatchLink({ url: import.meta.env.VITE_API_URL ?? "http://localhost:8000" })],
})The terminating link must come last in the array; today it must also be the only element.
URL rules got looser, not stricter
"http://localhost:8000"works."http://localhost:8000/"works (trailing slash stripped)."http://localhost:8000/rpc"works too (idempotent normalization).
The endpoint always resolves to <origin>/rpc, so copy-pasting base URLs from environment configs can no longer produce a 404.
Checklist
- Replace flat client options with a
linksarray containing exactly one terminating link. - Bump adapter packages to
^0.13.0(or re-runpyrpc dev, which regenerates the template file for new setups). - Regenerated types land at
<client>/__pyrpc.ts; make sure your editor picks up the tsconfig paths alias (automatic via pyRPC tooling). - Search for old option names (
url:directly oncreateClient), TypeScript will flag these as type errors immediately.
That last point is the migration strategy in miniature: the compiler finds every call site. Fix them until it compiles; run your app; done.

pyRPC