feat: content type handling customization#2449
Open
mromaszewicz wants to merge 1 commit into
Open
Conversation
Contributor
Greptile SummaryThis PR adds
Confidence Score: 5/5The change is safe to merge; it adds an opt-in output option that leaves all existing generated output identical when the option is unset. No existing behaviour changes for specs that don't set No files require special attention. The JSON schema property-names gap in
|
| Filename | Overview |
|---|---|
| pkg/codegen/configuration.go | Adds ContentTypes field to OutputOptions, compileContentTypeNameTags with validation and sorting, and compile-time validation in Validate(). Defaults and regex compilation look correct. |
| pkg/codegen/operations.go | Rewrites GenerateBodyDefinitions and GenerateResponseDefinitions to route through activeContentTypeNameTags().TagFor() before falling back to vendored-JSON derivation. Adds IsFormdata, IsMultipart, IsText, HasModel predicates. The IsSupported semantic change (NameTag→media-type check) is consistent with existing logic. |
| pkg/codegen/content_types_test.go | Unit tests cover: short-name renaming, default-unchanged baseline, built-in rename with disambiguation, unsupported-type model generation, ambiguity error, and validation. Coverage is thorough. |
| internal/test/options/content_types/content_types.gen.go | Generated output looks correct: V1-mapped vendored JSON gets typed request/response/strict types; CSV-mapped body generates model alias but strict server uses io.Reader as documented. |
| configuration-schema.json | Adds content-types object property. The object's additionalProperties is correctly typed but the property names are not constrained to the Go-identifier pattern enforced at runtime. |
| pkg/codegen/templates/strict/strict-interface.tmpl | All eq .NameTag "Multipart"/"Text"/"Formdata" comparisons replaced with method predicates. Logic is equivalent for all pre-existing media types; new custom types correctly fall to io.Reader. |
| internal/test/options/content_types/content_types_test.go | Integration tests exercise compile-time type assertions, client V1-response parsing, CSV raw-body behavior, and strict CSV response streaming. Adequate coverage for the new test leaf. |
Reviews (2): Last reviewed commit: "feat: content type handling customizatio..." | Re-trigger Greptile
Partially addresses oapi-codegen#2368. Add an output-options.content-types setting: a map of short names (the tag spliced into generated type names, e.g. the JSON in FindPetsJSONRequestBody) to lists of regex patterns matched against request/response media types. Matching media types get models generated and named with the short name, so e.g. application/vnd.mycompany.v1+json can produce FindPetsV1RequestBody instead of a name derived from the media type. User entries are merged on top of the built-in defaults (JSON, Formdata, Multipart, Text) by key replacement; an empty pattern list disables a key. A media type matching patterns under two different short names is a generation-time error. Vendored +json naming and the client-side YAML/XML/HAL handling remain media-type-derived fallbacks, so an unset mapping produces identical output to before. To keep custom names from changing behavior, templates now branch on media-type-derived methods (IsFormdata/IsMultipart/IsText/IsSupported) instead of comparing NameTag strings, so wire-level handling (marshaling, binding) always follows the media type rather than the name. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
mromaszewicz
force-pushed
the
feat/content-type-matching
branch
from
July 10, 2026 23:58
452080c to
d24e195
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Partially addresses #2368.
Add an output-options.content-types setting: a map of short names (the tag spliced into generated type names, e.g. the JSON in FindPetsJSONRequestBody) to lists of regex patterns matched against request/response media types. Matching media types get models generated and named with the short name, so e.g. application/vnd.mycompany.v1+json can produce FindPetsV1RequestBody instead of a name derived from the media type.
User entries are merged on top of the built-in defaults (JSON, Formdata, Multipart, Text) by key replacement; an empty pattern list disables a key. A media type matching patterns under two different short names is a generation-time error. Vendored +json naming and the client-side YAML/XML/HAL handling remain media-type-derived fallbacks, so an unset mapping produces identical output to before.
To keep custom names from changing behavior, templates now branch on media-type-derived methods (IsFormdata/IsMultipart/IsText/IsSupported) instead of comparing NameTag strings, so wire-level handling (marshaling, binding) always follows the media type rather than the name.