You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The way this seems to work is that the parameters of the function following the @typedef are added to the @typedef object. Moving the @typedef to the bottom of a file fixes the issue.
Thanks for the report! This is the 'multi-signature' support getting out of hand, it's assuming that you want to document two variants of a function, and still doing inference. As a stopgap, you can use the @name tag to name the thing NumberLike and it'll turn off inference. But we should fix this in core, since it's definitely spooky behavior.
tmcw
changed the title
@typedef objects get @params of following function
@typedef and @interface comments should not have parameter inference, possibly not any?
Jul 28, 2017
Q I have is: should interface and param comments get no inference? I think typedef should have properties inference. So far it's been all-inference-on-all-comments, but this is suggesting that it might be mix & match.
Or, well, I'm also open to removing the multi-signature support, which seems ambiguous in a way that will always be problematic.
When generating documentation of the jsdoc @typedef example, documentationjs adds 'x' as a parameter to the object NumberLike.
The way this seems to work is that the parameters of the function following the @typedef are added to the @typedef object. Moving the @typedef to the bottom of a file fixes the issue.
`/**
*/
/**
*/
function setMagicNumber(x) {
}
`
The text was updated successfully, but these errors were encountered: