Propagate type-level OpenAPI extensions to computed body types - #3941
Merged
Conversation
The HTTP request and response body builders wrap design types into computed body user types and only carried over the "openapi:typename" and "openapi:additionalProperties" meta. Type-level "openapi:extension:x-*" meta was silently dropped so extensions declared on types never reached the generated schema components. Copy the OpenAPI schema meta in one helper shared by both builders and document that "openapi:extension:xxx" applies to types. This enables designs to drive schema-level tooling extensions, for example Speakeasy's x-speakeasy-include which forces SDK generation for schemas only referenced from OpenAPI 3.2 SSE itemSchema documents. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.
Why
Meta("openapi:extension:x-...")declared on a type never reached the generated OpenAPI documents. The HTTP body builders (expr/http_body_types.go) wrap design types into computed body user types (<Method>RequestBody/<Service><Method>ResponseBody) and only carried overopenapi:typenameandopenapi:additionalProperties— extension meta was silently dropped before the schemafier ran. The schemafier itself already renders attribute-meta extensions, so the components were the only missing link.Concrete motivation: schemas referenced exclusively from OpenAPI 3.2 SSE
itemSchema(e.g. typed SSE event payloads) are pruned as "unreferenced" by SDK generators like Speakeasy. The documented escape hatch isx-speakeasy-include: trueon the schema — which requires type-level extensions to actually render.What
copyOpenAPITypeMeta— one helper shared by the request- and response-body builders that copiesopenapi:typename,openapi:additionalProperties, and allopenapi:extension:*/swagger:extension:*keys from the original type to the computed body type (collapses the two previously duplicated copy blocks).dsl/meta.go: documents thatopenapi:extension:xxxapplies to types (OpenAPI schema object).type-extensionlocking the rendering in 3.0 documents.Compatibility
All pre-existing golden files pass without regeneration — output only changes for designs that already declare type-level extension meta, which previously rendered nothing.
🤖 Generated with Claude Code