🚀 Road to oRPC v2: Call for Ideas, Features & Feedback

[dinwwwh]

Hi everyone! 👋

We are starting to plan the next major version of oRPC (v2), and we want to build it with your input.

We aim to refine the DX, improve performance, and address architectural limitations. We need to know:

• Pain Points: What feels clunky, verbose, or confusing in v1?
• Wishlist: What features, integrations, or framework supports are missing?
• Breaking Changes: If you could redesign one part of the API from scratch, what would it be?

Please drop a comment below with your thoughts, code snippets, or just a +1 on ideas you like. Let's make v2 amazing! 🚀

[HamishWHC]

attaching errors to middleware please - if i have auth middleware that may throw a 403, using the middleware should attach that error.

[dinwwwh]

ready in v2.

[NeilTheFisher]

I'd like to be able to return a Response from a handler, making return fetch possible

[dinwwwh]

Related: #1058

[muniter]

So much this. It's the only thing that forces me to have my HTTP handlers in two places: ORPC and the web framework.

[NeilTheFisher]

also related: https://github.com/unnoq/orpc/issues/954

[dinwwwh]

v2 support returning ReadableStream<Uint8Array> so it easily to extend with plugin to support Response too

[HamishWHC]

Stabilize ArkTypeToJsonSchemaConverter.

[dinwwwh]

ready in v2.

[strblr]

Overall the thing is struggle most with are Typescript errors when I have lots of middlewares used in different combination. Not sure how it can be improved though.

Would also be very nice to be able to define middlewares that transform regular output into eventIterator. So we can have a liveQuery middleware for example, that calls the handler when a Publisher emits something, and the handler is a regular function (not a generator).

[razfriman]

I know it’s complicated, but it would be amazing if OpenAPI output schema could be determined dynamically inferred on the return type of the handler

[yacobmole]

This isn't a limitation on oRPC; TypeScript types don't exist at runtime, so they can't be used to dynamically infer schemas. OpenAPI generation happens at runtime, which makes inferring the output schema from the handler's return type impossible.

Actually, you could generate something at build/dev time, that analyze the types that can then be used in runtime.

Btw, apparently Elysia do it: https://x.com/saltyAom/status/1969464092806238290?t=ooNhMsoYNhEjgg6WFB_Ysg&s=19

You are right in the fact that elysiajs do infact achieve this, But this is not runtime agnostic as this requires to statically analyse the source files, which may not be available even on the compatible runtimes. Source.

oRPC is not a framework, this would be outside its scope. I believe a thirdparty/external tools should be used instead.

Should your compiled code be reading your source code files at runtime, No.

[theoludwig]

But this is not runtime agnostic as this requires to statically analyse the source files, which may not be available even on the compatible runtimes.

The spec generation is not meant to be run in the browser, instead, Scalar/Swagger web UI calls for example /spec.json from your API, which is generated. Node.js has a fs module, and most server-side runtimes has the same compatibility as Node.js, e.g: Bun/Deno. So I'm not sure, what you mean, not available, as the spec is generated server side.

---

oRPC is not a framework, this would be outside its scope. I believe a thirdparty/external tools should be used instead.

Call it however you want, that's only words. Even React, call themselves a library and not a framework (and consider that Next.js, TanStack Start, Remix are the "frameworks" of React), but one could argue, that React is itself a framework.

Ideally, we could use oRPC with the Node.js builtin http:server to do everything, and that's it, no need to use Fastify, Nest.js, H3, Hono or whatever "framework" on top of it. oRPC is sufficient by itself with node:http.

I don't understand why it would be out of the scope of oRPC. It would be very convenient to use @orpc/openapi, and get automatic documentation from our route handlers. But I saw that @unnoq reacted with 👍, and obviously the maintainer has the final word, to what is out of the scope or not of the project. Would you mind explaining why it would be out of the scope for oRPC? Is it because, it would be too hard to implement/to maintain/other reasons?

---

Should your compiled code be reading your source code files at runtime, No.

Personally, I'm not compiling/transpiling my Node.js server code, but use the builtin Type Stripping from Node.js: https://nodejs.org/docs/latest/api/typescript.html (which is transpile at runtime to remove types specifier, to be able to execute the code).

"at runtime", as said, it's not necessarily a thing at runtime, the spec.json could be generated with a CLI command, before running the server-side runtime code, which will then just fs.readFile the already generated spec.json.

[NeilTheFisher]

oRPC is not a framework, this would be outside its scope

I disagree, it could easily just be another package under @orpc/ if unnoq would like it to be. I don't see a reason to limit the scope in this case.

Should your compiled code be reading your source code files at runtime

Yeah the schema generation would have to be done before compilation. After compilation was never a goal here (and impossible)

---

If I have free time I wouldn't mind making a package for this. I was thinking of potentially modifying the way the openapi schema generator works but I'd have to look into it

[yacobmole]

The spec generation is not meant to be run in the browser, instead, Scalar/Swagger web UI calls for example /spec.json from your API, which is generated. Node.js has a fs module, and most server-side runtimes has the same compatibility as Node.js, e.g: Bun/Deno. So I'm not sure, what you mean, not available, as the spec is generated server side.

oRPC explicitly advertises multi-runtime support, https://orpc.dev/#:~:text=Multi%2DRuntime%20Support. By requiring the fs module you now have to use a nodejs compat runtime. This breaks true runtime agnosticism.

Call it however you want, that's only words. Even React, call themselves a library and not a framework (and consider that Next.js, TanStack Start, Remix are the "frameworks" of React), but one could argue, that React is itself a framework.

React is a library, libraries help you accomplish a couple tasks; frameworks define your whole project.

Would you mind explaining why it would be out of the scope for oRPC? Is it because, it would be too hard to implement/to maintain/other reasons?

"at runtime", as said, it's not necessarily a thing at runtime, the spec.json could be generated with a CLI command, before running the server-side runtime code, which will then just fs.readFile the already generated spec.json.

A long side what unnoq mentioned in their comment to your issue, oRPC is a library and should not require a build step. Statically analysing then generating a openapi.json file is another build step required in a CI/CD pipeline, and CI/CD already takes enough time.

Now you could skip the build step and generate the spec at runtime on each request but it would as i mentioned early have to read your source typescript code to generate the spec costing more Disk Reads + CPU Time. But not all projects will have the source typescript files available, consider a Typescript application compiled to NodeJS JavaScript and then packed into a docker image; You have the fs module but no source code causing spec generation to fail.

Personally, I'm not compiling/transpiling my Node.js server code, but use the builtin Type Stripping from Node.js: https://nodejs.org/docs/latest/api/typescript.html (which is transpile at runtime to remove types specifier, to be able to execute the code).

Not everyone is doing this. Personally I'm compiling/transpiling my Node.js server code.

[yacobmole]

I disagree, it could easily just be another package under @orpc/ if unnoq would like it to be. I don't see a reason to limit the scope in this case.

Major oRPC features i would expect to be aligned with oRPC values such as Agnostic Runtime Support as its one of the Selling points of oRPC.

Yeah the schema generation would have to be done before compilation. After compilation was never a goal here (and impossible)

While I understand generating the OpenAPI spec at build time (pre-compilation) might seem feasible, oRPC is fundamentally a runtime library, not a codegen tool; Requiring a separate build step I believe goes against its design principles.

Don't get me wrong, I'm not against inferring types to generate a OpenAPI spec, but I'm against the current methods that are being used, they come with many limitations, disadvantages and of course more build steps.

[tpetry]

Its a small thing. But I think this

const server = createServer(async (req, res) => {
    const result = await handler.handle(req, res, {
        ...options
    })

    if (!result.matched) {
        res.statusCode = 404
        res.end()
    }
})

could be simplified to this

const server = createServer(handler.handle, options)

because the 404 part is probably the same for everyone. So the only reason we need code within the req-res-callback is to set options for the handler - which could also be set on the server. Less code means its more easy to understand and easier for newcomers.

[dinwwwh]

But what if you have multi handlers? I think current approach make oRPC easy to embed to any existing framework.

[tpetry]

Oh I forgot that you can do this as I only have one handler. Yeah, then it doesn't make sense.

[Prains]

codegen. types generation to use in frontend props.

[pumpkinlink]

You can just use InferClientOutputs https://orpc.dev/docs/client/client-side#infer-client-outputs

[Zonigaru]

Easy integration with message brokers such as Nats.io, RabbitMQ, etc. For now, I have implemented a custom Link/Handler for Nats.io, but it's a bit tricky with ServerPeer to transfer native messages.

[dinwwwh]

Can you share more detail, how it can improve?

[strblr]

Documented support for tanstack AI.

[tpetry]

nice-grpc has a great feature that you can set retries and timeouts on the client and the rpc call. Setting defaults on the client is a nice feature as you don't have to remember to do it on every invocation.

const client = createORPCClient(new OpenAPILink(contract, { url: '...' }, {
    retries: {
        planet: {
            list: 3,
            find: 3,
            create: 1,
        }
    },
    timeouts: {
        planet: {
            list: 1_000,
            find: 1_000,
            create: 5_000,
        }
    },
});

This could use the contract and ensure you're only setting retries/timeouts for registered rpc calls.

[nicognaW]

been trying to combine vercel resumable-stream with oRPC 👀

[dinwwwh]

What about this by increase exp date to 24h for example: https://orpc.dev/docs/helpers/publisher

[johnpyp]

Related: https://github.com/durable-streams/durable-streams

[dinwwwh]

Here my example: https://github.com/unnoq/orpc-resumable-stream

[luciensolteo]

It would be great to have explicit separation between queries and mutations in procedure definitions, similar to tRPC’s approach. Currently, the inferred oRPC client doesn’t distinguish between query and mutation procedures, which means queries could be exported as mutations and vice versa.
This distinction is valuable because:

• It makes the API contract more explicit and self-documenting
• It enables client-side optimizations (queries can be cached, mutations trigger refetches)
• It prevents accidental misuse (e.g., performing side effects in what should be a read-only operation)

I feel that the current recommandation with a filter on keywords in the client definition isn't ideal

[strblr]

That's something that I much prefer on oRPC compared to tRPC to be honest. Always disliked how in tRPC subscriptions were this special thing that needed special React hooks to consume. In oRPC, regular handler + useQuery + a helper function, almost totally transparent.

You can also do this:

import { userQueries, userMutations } from "./user.ts"
import { todoQueries, todoMutations } from "./todo.ts"

const router = {
  query: {
    user: userQueries,
    todo: todoQueries
  },
  mutation: {
    user: userMutations,
    todo: todoMutations
  }
}

[Faithfinder]

First-class support for usage without the server part, clearly described in docs. Including request and response validation on the client :)

I think you kinda can do that now already? But that's my use case as I want to migrate away from dead zodios.

[dinwwwh]

Yes it is possible now,

• https://orpc.dev/docs/contract-first/define-contract
• https://orpc.dev/docs/plugins/request-validation
• https://orpc.dev/docs/plugins/response-headers

[ryanxcharles]

be able to easily generate a client for external consumption without depending on anything from the server (maybe this already exists and i don't know about it ?). e.g., my api-server project should be able to generate an api-client project which does NOT have server dependencies like database, etc.

[dinwwwh]

Contract-first approach can help you deal with this problem: https://orpc.dev/docs/contract-first/define-contract

[j3sch]

Maybe a logger plugin, which can also be used in serverless environments like cf workers.

As far as I know, the current "Pino Integration" doesn't work for Cloudflare Workers.

[pumpkinlink]

i'm using orpc pino integration in Google Cloud Run, which is another serverless environment, I had to use @google-cloud/pino-logging-gcp-config package, which is basically just a Pino config for GCP, so nothing to do with oRPC. I believe the same is valid for Cloudflare, you'd just have to do it manually

[ValentinGurkov]

I'd vote for a more abstract logger, for example, ours is a wrapper over winston with open telemetry things added in. I would be nice to be able to use it if oRPC just asks for a LoggerInterface that we must conform to

[dinwwwh]

@ValentinGurkov Actually oRPC only rely on pino interface, you can you any logger that satisfy that interface. Or is there any standard-logger library?

[ValentinGurkov]

@unnoq well, the docs state that we need to import things from @orpc/experimental-pino, so I was not aware that it can work with others

[dinwwwh]

v2 will support evlog.dev - edge ready.

[KingSora]

I'm not sure whether this is already possible (at least its not mentioned anywhere) but for ORPC v2 it would be cool to have a possibility to disable validation in favor of performance in production without disabling transformations of e.g. dates.

[dinwwwh]

Can you explain more about "without disabling transformations of e.g. dates."?

[KingSora]

Validation libraries like zod usually not only do data validation but they also do data transformation. E.g. define a Date as a string and if the string is a valid date-string the parsing will output a date object from the passed string.

This validation and transformation is not for free and will cause APIs to be slower because of it, but in production one could argue that the validation could be skipped while the transformation part still needs to run so the data-types are correct. hey-api for example splits those two conerns into validation and transformation entirely and allows both to operate independently.

In orpc v1 we have the input and output structure objects which are ment to do both of these things without the possibility to split them. On the other hand there is also the Smart Coercion Plugin which does the transformation part automatically.

The goal would not be to strictly split them, but the be able to skip the validation without skipping the transformation

[KingSora]

@dinwwwh do you have thoughts about this?

[dinwwwh]

Standard Schema does not support separating validation from transformation, so this kind of feature is not being considered. Since you mentioned a Smart Coercion Plugin, you can implement this behavior through a custom plugin tailored to your use case.

[dinwwwh]

If you don't know you can completely disable input/output validation with plugin.

[KingSora]

Support for the Temporal API for date, datetime and duration would be great in v2 :)

[nghiepdev]

It would be great to have a built‑in RPC playground, independent of OpenAPI—similar to GraphiQL, but for RPC.

We could explore and invoke procedures directly in the browser, with inputs, outputs, and auto‑complete, all driven by the oRPC contract.

No OpenAPI generation, Postman, or external tools are required.

[inducingchaos]

I guess the main one for me at the moment as I'm migrating to Effect, is defining the key points where oRPC holds an advantage over Effect's primitives for networking, errors, and typing.

I understand there's so many useful features in oRPC, but there's also so much overlap that it's hard to justify using both.

For those of us using Effect:

1. What are the main components of oRPC to use (and to not use) over Effect's primitives for speed, ergonomics, and interoperability?
2. What are the best ways to integrate (at the boundary between oRPC and Effect)? Would you recommend an adapter library like effect-orpc or is it better to use the handles you expose? Will there be any Effect-specific integration helpers in v2?

I'm not that deep into the migration yet, but because there's so much overlap, I'm wondering if you would still recommend oRPC over Effect RPC/HTTP, Schema, etc.

Would love to hear your detailed perspective here. Thank you!

[dinwwwh]

oRPC v2 will provide a simple Effect integration.

I'm not that deep into the migration yet, but because there's so much overlap, I'm wondering if you would still recommend oRPC over Effect RPC/HTTP, Schema, etc.

I don't have a strong answer for that yet - feel free to try both and see which fits your needs better. That said, I believe oRPC is currently one of the most feature-complete RPC libraries available, with many capabilities that Effect RPC/HTTP doesn't provide today.

[ahmafi]

Static file server helper function. Something like:

os.handler(fileServerHandler('./public'))

Hono has similart helper function serveStatic

[strblr]

This would be incredibly useful. I would use it in all my oRPC projects.

[ahmafi]

I think that will work too. Not sure which one is better.

[nghiepdev]

I think this falls under the responsibility of the adapter you're using, as in your Hono example.

[dinwwwh]

@nghiepdev It's similar to the CORS or compression plugins: a common enough use case that I think oRPC should support it directly. Not every use case needs to be built in, but for most common scenarios, users shouldn't have to reach for a third-party library like Hono.

[ahmafi]

Yeah exactly, I'm not even using Hono, I'm just using node http, and without this I have to add another third party package or write it myself.

[strblr]

One niche utility that would be nice is a helper to create these generic client-side proxies like the one returned by createTanstackQueryUtils. Would be helpful for custom TanStack Db integration, but could be used for more than that.

[ahmafi]

Client links should also accept relative paths instead of full URL. Different hosts can call the API and I want the keep the original host.

const link = new OpenAPILink(contract, {
    url: `/api`,
});

[dinwwwh]

Already support in v2.

[ahmafi]

OpenAPI 3.2 support? Finally we have nested tags in 3.2.

[RafalFilipek]

Support for describing parameters in cookies.

I created dedicated MR for v1: #1582

[KingSora]

One improvement which could be introduced in v2 is to change the .input() and .output() parameters to not always receive a schema object but also a plain object (for the inputStructure: 'detailed' / outputStructure: 'detailed' cases):

const updatePlanet = os
  .meta(openapi({
    method: 'POST',
    path: '/planets/{id}',
    inputStructure: 'detailed',
  }))
  // input is a raw object instead of z.object({})
  .input({
    params: z.object({ id: z.string() }),
    query: z.object({ dryRun: z.coerce.boolean().optional() }).optional(),
    headers: z.object({ 'x-trace-id': z.string() }).optional(),
    body: z.object({ name: z.string() }),
  });

With that, the inputStructure / outputStructure config in the .meta() could become obsolete because you could differentiate the input and output structure depending on whether the input parameter is a schema -> compact or an object -> detailed.

[dinwwwh]

This is planned, but I'm not sure it will make it into v2. I'm considering introducing a new extension, .detailedInput, that automatically sets the inputStructure metadata used by hooks.

[KingSora]

Regarding input and output, is there a way in v2 to define multiple content media types? For example a procedure could take application/json, application/octet-stream and application/xml as its requestBody and do different things then depending on the send content-type header.

[dinwwwh]

🎂 It's my birthday today, and I have a gift for you: oRPC v2 is now in open beta 🚀 https://v2.orpc.dev/

[ValentinGurkov]

Happy birthday!!! 🍰

[inducingchaos]

Happy birthday brother! Super excited for v2. Looks amazing so far

[KingSora]

Happy Birthday! :) (Today is also my birthday and I appreciate the nice gift!)

[anatoly314]

Proposal: server-initiated RPC over WebSocket in v2 (a callable client router)

To be precise up front: oRPC's WS is already full-duplex for data flow — within a client-initiated call the server streams back fine (event iterators, octet streams). The gap is server-originated requests: the server cannot start a new typed call to a specific connected client, because there's no client-hosted router for it to target.

This is baked into the v2 peer protocol: ClientPeer has .request(), ServerPeer doesn't, and ServerPeerSendMessage has no request kind — the server can only respond/stream/cancel. So every genuinely server-driven interaction (liveness/heartbeat, "server tells client to re-auth / invalidate session", pushing imperative commands, presence, server-orchestrated collaboration) has to be inverted into a client-opened event-iterator the server fans into. It works, but it's the wrong mental model and leaks into every such feature.

Since v2 is already reworking the WS layer (lazy mode, reconnection, connectionParams), this is the moment to make the peer protocol symmetric.

Proposal — let the client expose a router the server can call:

• Add a request kind to ServerPeerSendMessage and a .request() path to ServerPeer (the symmetric counterpart already on ClientPeer).
• Client optionally registers a clientRouter (its own contract — what the server may call).
• Server, per connection, gets a typed proxy to invoke it, end-to-end typed against the client contract.

// client — declare what the server may call on us
const link = new RPCLink({ websocket, router: clientRouter })

// server — initiate a typed call to a specific connection
handler.onConnection(async (conn) => {
  await conn.client.toast({ message: "saved" })   // typed against clientRouter
})

Notes

• Opt-in & backward compatible: omit clientRouter and it's exactly today's one-way model.
• Server→client calls reuse the connection's context for auth.
• Subsumes several ad-hoc "push" requests in this thread into one primitive.

[dinwwwh]

I don't understand the reasoning behind this. If you just want to show a toast, why not add an open event listener to the client WebSocket and call toast({ message: "Saved" })? Likewise, if you want to trigger something when the connection is established, why not add an open event listener to the server WebSocket?

Also, RPCHandler can be used on the client side, and RPCLink can be used on the server side. With the encode/decode prefix helpers, you can even reuse the same connection for multiple RPCLink/RPCHandler pairs. Technically, this is already possible. Supporting it across different adapters and setups just requires some additional work.

[r52j]

I understand there are technical reasons for replacing os.route({ … }) with os.meta(openapi({ … })) and os.meta({ key: "value" }) with meta plugins. Yet, these changes bloat the application code and make it more difficult to read. Especially as os.meta(openapi({ … })) doesn't really transport the impact of what can be set here (it's not just about setting metadata for the OpenAPI schema, but also about controlling routing and request parsing).

Perhaps it would be an option to add shortcuts for the standard behavior as implemented in v1, at least for the OpenAPI/route definition?

Thanks for your commitment to this great library!

[r52j]

Or perhaps an even better option would be to make the "meta plugins" extends the builder, so you could do

const base = os.plugin(openapiRoutePlugin);

const myRoute = base.openapiRoute({ … }).…;

or

const base = os.plugin(cachePlugin);

const myRoute = base.cache(true).…;

[dinwwwh]

it's not just about setting metadata for the OpenAPI schema, but also about controlling routing and request parsing

Personally, I see it as just metadata - it has no special meaning by default until something interprets it. If it's read by OpenAPIHandler/Link, it becomes routing info. If it's read by RPCHandler/Link, it has no effect at all. The same applies to custom metadata in general.

As for your proposed approach - it looks nice, but I think it could be fairly complex to implement. The current approach strikes a better balance between technical design and usability.

Perhaps it would be an option to add shortcuts for the standard behavior as implemented in v1, at least for the OpenAPI/route definition?

You can use .route ext for backward compatibility with v1: https://v2.orpc.dev/docs/openapi/routing#callable-extension

[ValentinGurkov]

I have another Next.js related wish list item for better integrating with partial pre-rendering and the errors thrown during that process:

.actionable() re-throws Next.js control-flow errors like NEXT_REDIRECT, which is great. But I use the safe client (createSafeClient) for RSC data reads, and it swallows everything into the [error, data] tuple — including framework control-flow. With Partial Prerendering that's now a real problem: a server read that touches cookies()/headers() during a prerender throws HangingPromiseRejectionError, the safe client eats it, and the Suspense boundary can't stream. So today I have to remember to call unstable_rethrow(error) on every safe-client read, which is easy to forget.

Two things I noticed digging into it:

1. The safe client has no framework awareness at all — safe() returns any throw as a tuple. .actionable() is the only place that re-throws, via error.digest.startsWith("NEXT_").

2. That NEXT_ prefix check is incomplete even for actionable. The full set Next's own unstable_rethrow re-throws:

error	identifier	starts with NEXT_?
redirect / permanentRedirect	NEXT_REDIRECT	✅
notFound / forbidden / unauthorized	NEXT_HTTP_ERROR_FALLBACK	✅
prerender interrupted	NEXT_PRERENDER_INTERRUPTED	✅
hanging promise (dynamic read during prerender)	HANGING_PROMISE_REJECTION	❌
dynamic server usage	DYNAMIC_SERVER_USAGE	❌
bail out to CSR	BAILOUT_TO_CLIENT_SIDE_RENDERING	❌
React postpone	$$typeof === Symbol.for('react.postpone')	❌ (no digest)

Plus it recurses into error.cause. So the prefix check misses the PPR-critical ones, and the set drifts across Next versions — a hand-maintained list will always lag.

Would it make sense for the safe client (ideally every catch site) to be able to re-throw these? I don't want to prescribe an API — you know oRPC's direction far better — but the one property I'd hope for is that it stays framework-agnostic: something like a host-supplied shouldRethrow?: (error) => boolean (default no-op) that Next users point at unstable_rethrow and other frameworks fill in themselves, rather than oRPC hardcoding Next internals.

For now I'm working around it by wrapping the safe client in a Proxy that runs unstable_rethrow on the tuple's error before returning it — happy to share if it's useful, but it's the kind of thing I'd rather not maintain per project.

[dinwwwh]

Please open a PR to cover all errors that should be thrown, and add an option to override the default rethrow behavior. Thanks for the information!

[dinwwwh]

#1668

[ValentinGurkov]

Hey, this is amazing! Though I was also thinking how this can work with procedures where we don't do .actionable(), meaning non-server actions

[dinwwwh]

I think it fine in v2 since .actionable not available by default: https://v2.orpc.dev/docs/integrations/next#createserverfunctionable

[sugurutakahashi-1234]

Proposal: official MSW integration (@orpc/msw)

Context. MSW + Storybook is the de-facto standard workflow for UI development and testing (Storybook stories, @storybook/addon-vitest browser tests, and e2e can all share the same network-level handlers). The tRPC ecosystem has msw-trpc filling this role, but oRPC currently has no equivalent for RPC link users — the only community attempt (orpc-msw) targets the OpenAPI link only and has been inactive at v0.1.0. Today, every team using the RPC link with MSW ends up hand-writing the { json: ... } wire format in their handlers (we do this in production at my company).

Key design principle: never reimplement the wire format. I think the reason no community package has stuck is that faithfully tracking the RPC protocol (serializer meta for Date/Map/Set/BigInt, error envelope, batch plugin) is exactly the part that goes stale. An official @orpc/msw can avoid this entirely by being a thin typed façade that delegates all serialization to the existing runtime — e.g. internally building an implement(contract) mock router served through RPCHandler (or reusing the official RPC serializer directly). The package would then be ~zero maintenance: protocol changes in core are picked up automatically, and the SDK only owns DX.

API sketch (mirroring msw-trpc ergonomics):

import { createORPCMSW } from '@orpc/msw'

const mock = createORPCMSW(contract, { baseUrl: '/rpc' })

export const handlers = [
  // fully typed from the contract: input is typed, return value is checked against output
  mock.planet.list.handler(({ input }) => [{ id: 1, name: 'Earth' }]),

  // typed errors declared via .errors({...}) on the contract
  mock.planet.find.error('NOT_FOUND', { message: 'not found' }),

  // never-resolving handler for loading states in Storybook
  mock.planet.create.loading(),
]

Per-procedure handlers (rather than one catch-all) keep MSW's ordinary composition model working, which matters for Storybook where individual stories override specific routes via parameters.msw.handlers.

Scope. RPC link first (that's the gap); OpenAPI link support could follow later since the same façade can sit on OpenAPIHandler.

I'd be happy to contribute this as a PR or develop it as a package under whatever structure fits v2 planning. Would love to hear whether an official MSW integration is in scope for v2.

[dinwwwh]

#1899