You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe. Actual: We have a problem with having & Record<string, any> added at each generated schema type definition. This does not seal (restrict additional properties) to the schema.
Describe the solution you'd like Expected: In ideal Scenario there would be a flag (to a generate function - additional generate option) that controls this feature - either makes the generated Schema files strict (what we refer to as sealed) or if set to false (default behaviour) would add the & Record<string, any> type union, allowing the types to be flexible (non restrictive).
Thanks for raising up.
Before talking about the solution, I would like to understand the root cause of & Record<string, any>, because we are woking on some improvement for this direction.
Maybe @shibeshduw can correct me, it seems this is related to the special keywords of the specification file like allOf, anyOf, oneOf.
@uroslates , please share a minimal example of the spec, so we can reproduce the issue.
Hey @jjtang1985, this is not related to the special keywords in the spec. I believe this is the default behavior with how OpenAPI interprets schemas.
In an object schema, even if additionalProperties is not specified, it is implicitly allowed (defaults to true), which means the object can have additional properties of any type. While parsing the spec, we default to type: any so that this behavior is captured. This in turn, causes the serializer code to append & Record<string, any> to the schema type definition.
Is your feature request related to a problem? Please describe.
Actual: We have a problem with having
& Record<string, any>
added at each generated schema type definition. This does not seal (restrict additional properties) to the schema.Describe the solution you'd like
Expected: In ideal Scenario there would be a flag (to a generate function - additional generate option) that controls this feature - either makes the generated Schema files strict (what we refer to as sealed) or if set to false (default behaviour) would add the
& Record<string, any>
type union, allowing the types to be flexible (non restrictive).Impact / Priority
The problematic code is relevant to
serializeObjectSchema
function.Example: Instead of having schema file outputs from openapi
generate
function like this:Would be good to have them (if correct generate options flag is set) like this:
The text was updated successfully, but these errors were encountered: