Skip to content

JSDoc support for destructured parameters #11859

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

Open
kitsonk opened this issue Oct 26, 2016 · 12 comments
Open

JSDoc support for destructured parameters #11859

kitsonk opened this issue Oct 26, 2016 · 12 comments
Labels
Domain: JSDoc Relates to JSDoc parsing and type generation Help Wanted You can do this In Discussion Not yet reached consensus Suggestion An idea for TypeScript VS Code Tracked There is a VS Code equivalent to this issue
Milestone

Comments

@kitsonk
Copy link
Contributor

kitsonk commented Oct 26, 2016

TypeScript Version: 2.0.3

Code

interface Foo {
    /**
     * A bar value
     */
    bar?: string;
}

/**
 * A function
 *
 * @param foo A param
 * @param { bar } Another param
 * @param bar Another param
 */
function foo(foo: string, { bar }: Foo): void {
    bar;
    foo;
}

foo('bar', { bar: 'play' });

Expected behavior:

Intellisense for the second argument, or the second argument properties.

Actual behavior:

No way of providing a description for the destructured elements of a destructured parameter.

destructured

@steph643
Copy link

+1
As a JS developer relying on destructuring for function parameters, this issue generates a lot of false "problems" when mixing parameters with and without default values.

@eduardobcastro
Copy link

This does not work on version 1.21.1

/** Class representing a user. */
module.exports = class User {
  /**
  * Create a User.
  * @param {object} user
  * @param {string} user.id - The user id in uuid format
  * @param {string} user.name - The user name
  * @param {string} user.email - The user email
  * @param {string} user.password - The user password
  */
  constructor({id, name, email, password}) {
    this.id = id
    this.name = name
    this.email = email
    this.password = password
  }
}

@hellos3b
Copy link

hellos3b commented May 1, 2020

Also an issue when functions return an interface

interface Returns {
  /** This object contains a getter that returns itself */
  get: (key: string) => string;
}

const buildObject = (): Returns => ({
  get: key => key
})

// shows jsdoc description when hovering over "obj1.get"
const obj1 = buildObject();
const a = obj1.get("key")

// Only shows signature "const get: (key: string) => string"
const {get} = buildObject();
const b = get("key");

edbentley added a commit to edbentley/replay that referenced this issue Oct 6, 2020
Note we could move the jsdoc comments to this interface.
But there's an open issue with it:
microsoft/TypeScript#11859 (comment)
edbentley added a commit to edbentley/replay that referenced this issue Oct 22, 2020
* Set jumpToFrame async to avoid blocking event loop

* Stop getByText throwing errors

* Add explicit return type for testSprite

Note we could move the jsdoc comments to this interface.
But there's an open issue with it:
microsoft/TypeScript#11859 (comment)

* Include userland stack trace in jumpToFrame
@zachhardesty7
Copy link

Also would really like to have the comments made in my interface show on hover of destructured variables. In the mean time, has anybody found a workaround? I destructure code all over the place and can't figure out how to document the variables.

@mesqueeb
Copy link

mesqueeb commented Mar 9, 2021

@edbentley
I'm very interested in your last commit concerning this issue.

What did you mean with

Note we could move the jsdoc comments to this interface.

I'm experiencing the same issue where destructured function params don't show the JSDoc comment. : S

@edbentley
Copy link

@mesqueeb I just meant that it wasn't worth moving the existing JSDoc comments to the interface since they still won't show.

@eps1lon
Copy link
Contributor

eps1lon commented Apr 17, 2021

Would like to see this implemented for the basic case:

interface Options {
  /**
   * description
   */
  param?: string;
}
const options: Options = {};
// `param` has no JSDOC
const { param }  = options

Any pointers where the implementation should happen (and tests)?

Should the description also be carried over if the destructured value has a default value e.g.

// Should `param` have the description of `options.param`?
const { param = 'someDefaultValue' }  = options

@saschanaz
Copy link
Contributor

Any pointers where the implementation should happen (and tests)?

Maybe https://github.com/microsoft/TypeScript/blob/master/src/services/jsDoc.ts ?

@rohit-gohri
Copy link

rohit-gohri commented Apr 22, 2021

Looking at this issue a year after subscribing to it, I feel the requirement doesn't make sense if we look at the implications of supporting this. Because if this is implemented then wouldn't it also mean carrying over descriptions at every assignment?

Since this

const { param }  = options;

is equivalent to

const param = options.param;

If the description is really important then maybe something like Nominal Types can be used so a reference to the original type is still around if not it's description, eg.:

image

TS Playground link

@MarcosAtApprentice
Copy link

This seems related to this weird issue I'm having with type inference on object destructuring. Posted about it here: #44730 (comment)

@PoulBak
Copy link

PoulBak commented Aug 8, 2022

Is JSDoc dead? This has not been fixed in almost 6 years.

@steida
Copy link

steida commented Nov 28, 2023

So effectively, JSDoc shall not be used to document TypeScript code. Fortunately, we can use markdown.

Eg. "### Example with ```ts"

A weird thing is, that "@link" can be used. "@param and @example" not.

steida added a commit to evoluhq/evolu that referenced this issue Nov 28, 2023
I spent many hours figuring out why docs are sometimes shown and sometimes not.

microsoft/TypeScript#11859
shvlv added a commit to shvlv/gutenberg that referenced this issue Oct 15, 2024
See microsoft/TypeScript#11859. Essentially JSDoc should not be used for Typescript
shvlv added a commit to shvlv/gutenberg that referenced this issue Dec 31, 2024
See microsoft/TypeScript#11859. Essentially JSDoc should not be used for Typescript
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Domain: JSDoc Relates to JSDoc parsing and type generation Help Wanted You can do this In Discussion Not yet reached consensus Suggestion An idea for TypeScript VS Code Tracked There is a VS Code equivalent to this issue
Projects
None yet
Development

No branches or pull requests