Because oRPC support lazy routers so resolveContractProcedures return a promise is expected.

If you don't care about lazy router, you can use traverseContractProcedures and don't care about return

Open in StackBlitz

npm i https://pkg.pr.new/mmkal/trpc-cli@105

commit: d633214

Because oRPC support lazy routers so resolveContractProcedures return a promise is expected.

If you don't care about lazy router, you can use traverseContractProcedures and don't care about return

Perfect, much nicer - thanks @unnoq! Damn you really thought of everything. As I was writing it I was thinking "there should be a method just like this one but that synchronously returns the lazy router paths" and then exactly that exists. Has happened many times with orpc.

This is included in v0.9.0.

Hey @mmkal. It's possible to put the trpc/server dep as a development dependency?
I'm thinking in the following scenario: If I, as a user, want to use only orpc I necessarily need to have trpc installed?

I go back and forth on this. The reason it's a prod dependency is to make it possible to write a CLI just by installing this library on its own. With trpc based CLIs this wasn't a big deal since you'd likely end up with only one version in node_modules even if you have your own separate trpc/server.

But with orpc, yes, there will be an unnecessary trpc/server in your/your users' node_modules.

Having said that it's a pretty lightweight, has no dependencies itself, and (I'm assuming) only used on servers (node/bun/deno) anyway? Is the concern just install size?