tRPC v9 feedback before marking it as `9.0.0`

I’ve just merged the #732 & #718 to main and released a new V9 draft.

Are there any other structural, potentially breaking changes that you would want to get into the next major?

• It should be production-ready so feel free to update your deps to 9.0.0-alpha.4, play around with it, and give me feedback.
• I have tried slowing down on the major version bumps, so I would ideally not do more breaking changes for a while.
• Planning to release 9.0.0 early next week.
• There might come a 10.x as well later in a month or so in order to add support for SvelteKit - might require some major changes as their API handlers are a bit different.

If you’re happy you can just give a 👍 on this issue.

Summary of changes so far

• Middlewares will now have to call a next() function that you have to call.
• Reduce TRPCErrors - METHOD_NOT_FOUND removed & PATH_NOT_FOUND renamed to NOT_FOUND (#733)
• Align input and output serialization (#746)
• Remove deprecated httpErrors-helper
• Remove support for ?input to be an array - now assuming a Record<number, unknown>-style dict (changed with backward compat in #669)
• Remove support for POST calls being { input: x } (originally from #671)
• 🛬 Incoming as well
  • #811
  • #816
  • #820

[mmkal]

I am also on vacation for the next couple of weeks, so can’t contribute code but can leave a couple of thoughts I’ve had here. I don’t think any of them would need to be breaking though, necessarily.

Middleware - it’d be really cool to be able to “refine” the context. Example for a router with type Context = { userId: string | null }:

.middleware(async ({ ctx, next }) => {
  const {userId} = ctx
  if (!userId) throw new ...

  return next({ ctx: { ...ctx, userId })
})
.query(...) // userId is non-nullable after this

---

Mentioned in #271 but an output: z.object({ ... }) prop just like input, would mean we could generate full openapi specs purely from trpc definitions.

---

Just putting them out there, no reason I’m aware of they’d be breaking, but if you like the ideas and think they would require a breaking change then might be worth looking at.

Only other things I can think of is if #506 could be a technical breaking change for people constricting requests manually (i.e. without @trpc/client). Or if #755 could lead to a breaking change somehow.

Either way, I’m more than happy with v9 as it is and very much looking forward to it being stable!

[github-actions[bot]]

This issue has been locked because it had no new activity for 14 days. If you are running into a similar issue, please create a new issue. Thank you.