Best way to extend the schema generated by the OpenAPI Spec

[xeoneux]

I'm in a scenario where the backend sends us an OpenAPI spec which generates a very generic type that can be narrowed down on the frontend.

For example:

type AdditionalFrontendData = {
  additionalFrontendData: object
}

We have a frontend schema written in Zod like

const additionalFrontendData = z.object({ 
  username: z.string(),
  userId: z.number().multipleOf(5)
});

I was wondering what's the best way to extend this type "before" the generation of types so that we have this as the final output

type AdditionalFrontendData = {
  additionalFrontendData: {
    username: string
    userId: number
  }
}

Now, we also have some zod validations which we would like to use for types instead of the generated types
My questions here are:

1. What's the best way to extend the original OpenAPI schema with our Zod types so that the Zod schemas generated are enriched with our custom validations?
2. Should we use Zod types instead of generated TS types? Is there any advantage of that? I'm thinking more in terms of narrowing types, for example:

type AllLocaleIDs = `${EmailLocaleIDs | FooterLocaleIDs}_id`;
type Lang = "en" | "ja" | "pt";
type LocaleMessageIDs = `${Lang}_${AllLocaleIDs}`;

instead of just string?

[stijnvanhulle]

@xeoneux Right now we don't have support for overriding specific schema's. Is this something that could be changed before passing it to Kubb or should Kubb handle those cases (this will add some complexity to Kubb)?

[xeoneux]

If we change it before passing it to kubb, it will only be in the openapi format and zod schemas won't tie up perfectly with sub parts of the schema. Zod schemas are more expressive so I was thinking if there is a way (maybe using generators and also letting kubb know) to generate zod schemas with custom schemas injected inside