Closed robdodson closed 12 months ago
from the PR you linked, it looks like the OpenAPI spec behaves that way so I'd say it's correct to implement it this way and your OpenAPI might not be correct then (should have implicit additionalProperties: false
) ?
But I also get that you might not be able to control the OpenAPI generation, which is kinda the point of this lib 😅 so, 2 solutions I can think of that should support everyone's needs:
additionalProperties
when using a CLI/option flag
https://github.com/astahmer/openapi-zod-client/pull/163/files#diff-aff08f665d4e69fe50761cef05035287658147285c711089446e5cbbbadacb54R197-R200additionalProperties: false
before passing the document to openapi-zod-client
@astahmer the thing is, passthrough seems to break type inference somehow because zod add & [x: string]: unknown
. zod can't resolve the types when there are multiple objects with passthrough embedded.
i don't know a good solution here. zod could handle these case in their infer parser though. so maybe a better solution would be a fix on zod part ?
yes, this would be the ideal solution, not sure how feasible that is tho
from the PR you linked, it looks like the OpenAPI spec behaves that way so I'd say it's correct to implement it this way and your OpenAPI might not be correct then (should have implicit additionalProperties: false) ?
Ah yeah, it looks like the OpenAPI spec defaults additionalProperties
to true
additionalProperties - Value can be boolean or object. Inline or referenced schema MUST be of a Schema Object and not a standard JSON Schema. Consistent with JSON Schema, additionalProperties defaults to true.
Unfortunately it seems like Goa, the tool our backend team uses to write their endpoints, does not provide a way to set additionalProperties
to false
(stale issue)
either make a PR and reverse that change to additionalProperties when using a CLI/option flag #163 (files)
I would love if we could have a flag to force additionalProperties
to false
. I think that will be easier than traversing the spec.
i don't know a good solution here. zod could handle these case in their infer parser though. so maybe a better solution would be a fix on zod part ?
It looks like someone filed a similar issue in the Zod repo but it may be a TS problem ☹️
@robdodson it seems that using a Simplify Helper fixes it. i pinged collin on twitter to check where it would be more valuable to add it. I would prefer Zod to add it rather than zodios. Because then if zod breaks it in another way, we'll have to change again inference on zodios.
Version: 1.10.2
When I hover over the generated types for a response object, they include wrapping generics. I mentioned this in the Zodios discord and @ecyrbe said that this looked wrong, and that the types should be inferred.
I think my issue is related to this change: https://github.com/astahmer/openapi-zod-client/pull/163, which added
passthrough()
to the end of all object schemas. If I manually remove thepassthrough()
s, or use the version ofopenapi-zod-client
prior to this change, then the issue goes away.Test case: