-
Notifications
You must be signed in to change notification settings - Fork 42
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
Better support for typedef @property #135
Conversation
Given the following JSDoc ```js /** * @typedef {Object} BillboardGraphics.ConstructorOptions * * Initialization options for the BillboardGraphics constructor * * @Property {Property | boolean} [show=true] A boolean Property specifying the visibility of the billboard. */ ``` tsd-jsdoc was producing the following TS code ```ts /** * Initialization options for the BillboardGraphics constructor * @Property [show = true] - A boolean Property specifying the visibility of the billboard. */ type ConstructorOptions = { show?: Property | boolean; }; ``` `@property` is not valid TS markup and the actual property, show, does not include it's description or default value. After this change the same JSDoc markup produces much nicer code that handles both of these: ```ts /** * Initialization options for the BillboardGraphics constructor */ type ConstructorOptions = { /** * A boolean property specifying the visibility of the billboard. * @DefaultValue true */ show?: Property | boolean; }; ``` I updated the tests, to match the new output and manually verified its what I would expect.
src/type_resolve_helpers.ts
Outdated
|
||
// !parent ensures we are dealing with a top-level typedef. | ||
// So that the tsd-doc is added at the property level. | ||
if(!parent && (node.prop.description || node.prop.defaultvalue)) { |
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.
@englercj Is there a better way I should be checking this? The other option is threading the doclet
through the calls so that I have access to doclet.kind
here, which should be trivial to do but didn't want to make a bigger change before checking with you.
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 think this check is reasonable
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.
Looks good, just had some minor style suggestions.
Co-authored-by: Chad Engler <englercj@live.com>
Co-authored-by: Chad Engler <englercj@live.com>
Thanks @englercj, I accepted your changes so I think this is ready. |
Thanks @englercj! Any idea when tsd-jsdoc will get an updated npm release? |
@englercj Are there any plans to do a new release anytime soon? I would like to make use of this PR and I didn't want to fork/publish to a different package just to use it. I know you are busy and I'm still a complete stranger, but long term I have no problem helping out with maintaining this repository once I earn your trust, since CesiumJS is not dependent on it. Thanks! |
There are some bugs and regressions that came up recently. I'm waiting for those to get fixed first. |
Given the following JSDoc
tsd-jsdoc was producing the following TS code
@property
is not valid TS markup and the actual property, show, does not include its description or default value.After this change the same JSDoc markup produces much nicer code that handles both of these:
I updated the tests, to match the new output and manually verified its what I would expect.