-
Notifications
You must be signed in to change notification settings - Fork 390
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
fix: allow descriptions on enum refs #473
fix: allow descriptions on enum refs #473
Conversation
return definition.enum === schema.enum | ||
} | ||
return definition === schema | ||
} |
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.
I'm not sold that this is a particularly good solution 🙃 it feels weird to hardcode the case for enums. But I'm not familiar enough with the codebase to have any deeper insights.
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.
I noticed the same on #466, but not related to enums. In their case, they had a property like this:
"definitions: {
"status_block": {
"type": "object",
"properties": {
"experimental": {
"type": "boolean"
}
}
}
},
"status": {
"$ref": "#/definitions/status_block",
"description": "..."
}
See my comment for more details on why this happens.
For a more universal fix that goes beyond just enums, I wonder about:
- create a copy of the original json, set aside for step 4.
- cull certain fields from any subschemas that use
$ref
- (Now the $ref resolver can make the $ref referentially equal to what it's referencing, so that
json-schema-to-typescript
doesn't generate a new type (or inline, depending on what version you're using?). This won't work if there are fields not culled in step 2, of course) - During code generation, reference the original json for things like
description
, which shouldn't affect type relationships, but should certainly affect generated doc strings for properties.
wdyt?
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.
Honestly, although that sounds reasonable, I'm very new to this project and haven't done a deep dive into it. So if you say that's a good fix then I believe you! 😄
/**␊ | ||
* A first property.␊ | ||
*/␊ | ||
export type Shared = "a" | "b";␊ | ||
␊ | ||
export interface Enum {␊ | ||
first?: Shared;␊ | ||
}␊ |
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.
The property comment is in the wrong place
- /**
- * A first property.
- */
export type Shared = "a" | "b";
export interface Enum {
+ /**
+ * A first property.
+ */
first?: Shared;␊
}␊
Closing out stale PRs. Feel free to rebase and re-open if you'd like to revisit this PR. |
Fixes #472.