fix(ir): populate displayName for discriminated union variants#16691
fix(ir): populate displayName for discriminated union variants#16691devin-ai-integration[bot] wants to merge 4 commits into
Conversation
Co-Authored-By: rishabh <rishabh@buildwithfern.com>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| const explicitDisplayName = getDisplayName(rawSingleUnionType); | ||
| const displayName = | ||
| explicitDisplayName != null | ||
| ? explicitDisplayName | ||
| : parsedValueType.type === "named" | ||
| ? titleCase(getOriginalName(parsedValueType.name)) | ||
| : undefined; |
There was a problem hiding this comment.
🚩 Behavioral change: all named-type union variants now get auto-populated displayName
Previously, displayName for union variants was only set when explicitly provided via display-name in the Fern definition (always null otherwise). Now every variant referencing a named type automatically gets a displayName derived from the type's original name. This is a semantic change to the IR output that affects all discriminated unions across all generators and docs consumers. The snapshots show ~80+ null → string changes across many test definitions. While additive (the field already exists in the schema), downstream consumers that distinguish between null and a string value for displayName could behave differently. The changelog entry (packages/cli/cli/changes/unreleased/fix-union-variant-displayname.yml) documents this as a fix.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
This is intentional. The displayName field already exists in the IR schema and was always null for union variants without an explicit display name. The change is additive — downstream consumers that don't use displayName are unaffected, and those that do (like the docs renderer) will now show meaningful schema names instead of "object". The docs UI already handles both null (falls back to "object") and string values, so this change improves the display without breaking anything.
Docs Generation Benchmark ResultsComparing PR branch against median of 5 nightly run(s) on
Docs generation runs |
SDK Generation Benchmark ResultsComparing PR branch against median of 5 nightly run(s) on Full benchmark table (click to expand)
main (generator): generator-only time via --skip-scripts (includes Docker image build, container startup, IR parsing, and code generation — this is the same Docker-based flow customers use via |
Co-Authored-By: rishabh <rishabh@buildwithfern.com>
Co-Authored-By: rishabh <rishabh@buildwithfern.com>
…ants Co-Authored-By: rishabh <rishabh@buildwithfern.com>
Description
Discriminated union variants derived from named type references (e.g.
$ref: '#/components/schemas/VideoInput') were displaying as generic "object" in docs becausedisplayNamewas alwaysnullfor these variants. This fix auto-infersdisplayNamefrom the type reference name when no explicit display name is set.Changes Made
convertDiscriminatedUnionTypeDeclaration.ts: when a union variant has no explicitdisplayNameand its value type is a named reference, derivedisplayNameviatitleCase(getOriginalName(name))(e.g.VideoInput→"Video Input")anyof-ref-displaynamewith a minimal OpenAPI spec reproducing the issueunions.json,property-access.json,reserved-keywords.json,exhaustive.json) and ETE-test snapshots to reflect the newly populateddisplayNamevaluesfix-union-variant-displayname.ymlTesting
anyof-ref-displaynamefixture validates the fixLink to Devin session: https://app.devin.ai/sessions/7025b4dcebcd41c6946a314095ad8de3