feat: add OAS 3.1 contentMediaType and encoding.contentType support #2643
Conversation
… support - Binary contentMediaType/encoding.contentType → Blob type - Text contentMediaType/encoding.contentType → Blob | string type - encoding.contentType takes precedence over contentMediaType - Binary media key (e.g. application/octet-stream) overrides schema to Blob - Text/JSON media key causes contentMediaType to be ignored per OAS 3.1 - FormData generation: text types use instanceof Blob runtime check - Zod: binary → instanceof(File), text → instanceof(File).or(string()) - contentEncoding (e.g. base64) keeps type as string
Follow codebase standard of exact string matching with template literals instead of pattern matching. Consolidates 8 separate assertions into one comprehensive test covering all content type combinations.
- Add !item.format guard so contentMediaType doesn't override existing format: binary handling - Update comments to clarify OAS 3.0/3.1 relationship and Blob | string rationale
|
@snebjorn mind reviewing this one too? |
|
I found some issues and are still working on a more complete fix. Will submit a new version tomorrow. |
|
Excellent @superxiao thanks for reporting back |
…nd FormData - Replace callback-based propertyOverride with data-only propertyOverrides - Consolidate file type detection in getFormDataFieldFileType for all paths - Add direct TypeScript type assertion test for Blob vs Blob | string - Clean up docstrings and fix semicolon inconsistency in FormData output
|
Just wondering: currently, zod generation only processes // packages/zod/src/index.ts:1087-1092
// Only handle JSON and form-data; other content types (e.g., application/octet-stream)
// are skipped - unclear if this is correct behavior for root-level binary/text bodies
const jsonMedia = resolvedRef.content?.['application/json'];
const formDataMedia = resolvedRef.content?.['multipart/form-data'];Type generation handles this case - a request body with Is this intentional, or should zod generate |
|
I actually don't know what Zod is supposed to do for binary? |
…e overrides resolveFormDataRootObject now returns undefined when there are no file type overrides, allowing the caller to fall through to normal resolveObject which preserves reference names like Pet instead of inlining the dereferenced type.
I will ignore that issue then since there's no feature request for it. |
|
I don't have any more change in mind for this PR, feel free to merge when you think it's ready. |
|
thanks @superxiao ! |
2 participants
Adds support for OAS 3.1
contentMediaTypeandencoding.contentTypeto properly detect binary/file fields in OpenAPI schemas. This enables orval to correctly handle file uploads from tools like orpc that emitcontentMediaTypeviaz.file().contentMediaTypepresence → Blob type (unlesscontentEncodingis present or media key contradicts)encoding.contentTypeon string fields → Blob type (file upload intent)Blob; Text MIME types →Blob | stringinstanceof(File), text →instanceof(File).or(string())Why
Blob | stringfor text MIMEs?Binary data (images, audio) has no string representation—must be Blob. Text content (CSV, XML, plain text) can be passed either as a File or as a string directly (e.g., from a textarea or generated content). The runtime wraps strings in
new Blob([str], { type })automatically.Precedence: media key > encoding.contentType > contentMediaType > format
This unifies handling for both OAS 3.0 (
format: binary) and OAS 3.1 (contentMediaType). Existingformatsignals are respected first, and the new 3.1 signals only apply when noformatis present. A more spec-following approach is to handleformatonly for OAS 3.0 input andcontentMediaTypeonly for OAS 3.1 input. This PR opts for a simplerformat>contentMediaTypeapproach without looking at input OAS version, but can be updated later if needed.Related issues: #2636 #869
Test plan
isBinaryContentType()covering binary and text MIME typesFix #2636 #869