TypeScript: JSDoc comment for destructuring param: description text not displayed

@THoisington, for that to work, you need to first define a custom object for the options, and then define its properties. Then you assign that custom type as your parameter:

/**
 * Entries Object.
 * @typedef {Object.<string, any>} requiredArguments
 * @property {string} timeSince
 * @property {string} timeUntil
 */
/**
 * 
 * @param {requiredArguments} param
 */
async function getEntries({timeSince, timeUntil}) {}

That’ll give you IntelliSense for each property on the options parameter.

Is JSDoc dead? This is not solved after more than 4 years.

I’m having the same issue, I’m currently using javascript, and the solution provided by @lookuh partially implemented works in an awkward way.

When used the JSDocs comments in this way, it for sure won’t show the destructured params comments:

/**
 * @param {object} params
 * @param {stirng} params.id Some usefull id
 * @param {number} params.randomNumber Some randome number
 */

But when at least one of the param is defined as property, it starts to show the other params comments correctly, but it does not give type to them:

And a full typedef with @property solution isn’t showing the destructured params:

/**
 * @typedef MyParams
 * @property {string} id Some usefull id
 * @property {number} randomNumber Some random number
 * @property {Date} someDate Just a date
 */


/**
 * @function useCustomHook
 * @param {MyParams} params
 */

Hope this comment helps in any way.

That’s because TypeScript treats JSDoc types object and Object as any. You can designate a generic object using Object.<string, any>. So, redoing the above will give you the proper intellisense for id:

/**
 * @param {Object.<string, any>} arg
 * @param {number} arg.id - This param description will show up
 */
function foo({ id }) {}

// Intellisense for id will work
foo({id: 1})

Bumping up this. It’s a major issue. Destructured parameters have been around since ES6, and JSDoc has an official documentation on how to document them properly. They’re used everywhere, why was it never properly supported in VSCode’s JSDoc tooltips?

This is still an issue. The official jsdoc gives this example

/**
 * Assign the project to an employee.
 * @param {Object} employee - The employee who is responsible for the project.
 * @param {string} employee.name - The name of the employee.
 * @param {string} employee.department - The employee's department.
 */
Project.prototype.assign = function({ name, department }) {
    // ...
};

Found here https://jsdoc.app/tags-param.html#parameters-with-properties subheader - Documenting a destructuring parameter

I’d expect the tooltip to work if the jsdoc is correct per its own documentation

I have found the simplest cleanest solution for this mess.

/**
 * Main entrypoint and recommended function to use for route navigation.
 * @param {string} location - The path or url to navigate to, serves as a fallback url when goBack is true
 * @param {object} [config] - Additional configuration to alter the navigation
 * @property {object} [config]
 * @param {boolean} [config.replace] - If true, will use replace instead of push. This bypasses the browser history mechanism.
 * @param {boolean} [config.newTab] - If true, will open the url in a new tab, using window.open bypassing router
   * navigation.
 * @param {function} [config.callback] - If a function, will be called after navigation has ended
 * @param {boolean} [config.goBack] - If true, will use the browser history mechanism to go back. If going back leaves
 * the page, e.g. triggers beforeunload event, we warn the user, if he wants to stay in the page we redirect to the
 * provided url, which serves as a fallback.
 */

@Juanpam The problem here is that we lose the type definition of the arguments at the top. We can’t have both at the same time.

Interestingly, both the typedef and the integrated properties syntax work if you declare the argument you’re destructuring to be a @property instead of the @param that it is.

You are missing the empty line I added with the @property part.

@J3m5 I agree! Just my workaround for this issue. Still hoping this gets reviewed soon.