-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unsupported schema type: fhirprimitiveextension #18
Comments
looking at the JSON, it doesnt seem like it's supposed to generate anything, right ? in that case, you could parse/traverse the openapi JSON and remove any reference to that |
Apparently there are loads of unsupported types throughout the openapi.json. Maybe most of them are not important as you said? My first time working with OpenAPI, so I don't know if this is a "bad" spec or if they all require some cleaning. Would it make sense to not have unsupported types error out and instead make them something like unknown or nullable or any? I am using the Canvas Medical FHIR API: https://docs.canvasmedical.com/api/ My plan right now is to either manually clean the openapi.json, or attempt to convert their Postman Collections into OpenAPI which may give a better spec? I'm a bit lost 😂 |
converting the Postman Collections into OpenAPI worked well, and I was able to generate a zod client! 🎉 I am supposed to manually validate like this right? No out-of-the-box runtime validation?
Can close this issue if you are happy with how Unsupported schema type is handled. Thanks! |
glad that you found a solution !
yes, my intention for this library was to be "headless", by that I mean that it only provides the primitives to build your own type-safe API client (without any runtime by default !) in the fetcher (that you provides to the
as a lot of people have different needs, it's easier for me (in term of maintenance) to inverse the responsibility/control than having to integrate 100 different config options (like I did with that being said, if anyone comes up with a good default API client that validates etc by default, I'm fine with merging it in (as long as it's optional and that people can still create their own)
I think adding a callback to handle errors should make it easier to deal with, rather than having to pre-filter the openapi document (which I think it still a fine-ish solution) I'll leave the issue open if anyone wants to send a PR for those issues mentioned above |
The issue is coming from a FHIRPrimitiveExtension type. What are my options here? I am having the same problem with
openapi-zod-client
.Reference:
fhir-extensions
Here is the OpenAPI file:
openapi.json
The text was updated successfully, but these errors were encountered: