named schema objects in generated client/documentation

[elee1766]

hello its me again.

imagine you have a type like this:

const Ticket = z.object({
   id: z.string(),
   value: z.number(),
})

and an endpoints like this

{
        method: "get",
        input: z.object({}),
        output: Ticket,
        handler: async () => {
           return {id: "1", value:0}
        },
 }

say this is mounted on GET /ticket

When generating the client (using split response) i will get back something like

type GetTicketResponsePositiveResponse = {
  id: string
  value: number
}
type GetMarketOverviewNegativeResponse = {
    error: string;
};

type GetMarketOverviewResponse = GetMarketOverviewPositiveResponse | GetMarketOverviewNegativeResponse;

and same in the openapi schema in the responses.

However, it makes a lot more sense i think for this to be something like

type GenericError = {
  error: string;
}
type TicketSchema = {
  id: string
  value: number
}
type GetTicketResponsePositiveResponse = TicketSchema
type GetMarketOverviewNegativeResponse = GenericError
type GetMarketOverviewResponse = GetMarketOverviewPositiveResponse | GetMarketOverviewNegativeResponse;

the reason is that there is another post endpoint which consumes the ticket later. I understand that since the objects match up that it will satisfy the type check to pass the response from GetTicketResponsePositiveResponse the input in PostTicketInput, but that makes the client and the generated types incredibly messy. it would be great if the generated client could use the same type relationships that are expressed in the server-side schema.

digging through, i see there is a parameter serializer but that seems to be for lazy types.

otherwise, I suspected i would need to do something like

const Ticket = withMeta(z.object({
   id: z.string(),
   value: z.number(),
})).schemaName("Ticket")

but i did not see a feature like this in withMeta.

[RobinTail]

Hello @elee1766 ,

new Documentation({
  composition: "components",
  descriptions: {
    requestBody: ({method, path, operationId}) => { 
      /* your implementation here */
    }
  }
})

The string returned by the specified function is converted into PascalCase and used as a component name in the generated documentation.

Same for requestParameter, but its individual description given via withMeta().description() has a higher priority.

Naming of the Integration types is not supposed to be customized, since

• it's not a documentation;
• those types are not even exported;
• they are designed to be accessed via Input and Response interfaces using method and path.