Do not throw an error on undefined schema output

[chrisdobler]

In the case that you don't have the output defined for a particular route, this plugin will throw an error. I believe this should be considered an error because the TRPC documentation states:

In version 9 docs:
"This is entirely optional and only if you want to ensure you don't accidentally leak anything e"
https://trpc.io/docs/v9/output-validation

In version 11 docs:
"Validating outputs is not always as important as defining inputs, since tRPC gives you automatic type-safety by inferring the return type of your procedures. Some reasons to define an output validator include"
https://trpc.io/docs/server/validators#output-validators

So it seems like the definition of an output should be considered optional, and it is not reasonable that an error should be thrown if the output is not defined.

I'm sure there were very well thought out reasons why throwing an error was chosen, so please correct me if I am wrong here or if there is an edge case I am not understanding correctly.

[DJanocha]

Afaik generating types from runtime stuff (eg schemas) that occurs in trpc queries and mutations if doable, but not the other way around. I dont beliebe you can, with 100% positivity, generate validators from types. I like to think as types are just an IDE hints that unfortunately can lie.

Leta take an example of userSchema below:

const userSchema=z.object({
name: z.string(),
email:z.string().email(),
password: z string().min(8)
})
type User=z.infer
//that resolves to:
type User={
name: string
email: string,
password: string,

}

So the validation is lost and just IDE hints remain.

There are some generators that help you generate schemas from types but imo they would be hard to incorporate into a library- would it need the library’s code to change when it’s consumer’s (web app’s) code changes?