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
feat: support multipart form data encoding #3514
base: main
Are you sure you want to change the base?
Conversation
|
||
export const ObjectPropertySchema = TypeReferenceDeclarationWithNameSchema; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@abvthecity because we don't want to affect all object properties I would create a separate file called InlinedObjectPropertySchema
and leverage the TypeReferenceDeclarationWithContentType
type.
Then HttpInlineRequestBodySchema
can depend on the InlinedObjectPropertySchema
instead.
|
||
export const TypeReferenceDeclarationWithContentType = extendTypeReferenceSchema( | ||
DeclarationWithNameSchema.extend({ | ||
["content-type"]: z.optional(z.string(), { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@abvthecity Is this as simple as a string value that the generator needs to append?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not exactly.
the content-type
here can be a list of acceptable content-types, i.e. image/png, image/jpeg
.
the sdk should be able to infer the content-type from whatever file is being provided.
for string values (application/json), however, i think most likely yes. it's less likely (but not entirely impossible) to have a mixed text types... like text/plain
or text/xml
as variants that a single form entry might accept.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Beyond the comment about introducing a InlinedRequestBodyPropertySchema
- @abvthecity can you update the docs for the Fern Definition (link)
- Can we add a test for the OpenAPI parsing to make sure it works. You can use the existing fixture
- Ideally a validation rule that make sure
encoding
isn't used unless it is a MultipartFileUploadRequest (something like this)
encoding
field from openapicontent-type
field in openapi-ir, fern yaml-schema, and fern-irremaining steps: