Skip to content
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

Support import types in JSDoc links #43950

Open
mjbvz opened this issue May 4, 2021 · 6 comments
Open

Support import types in JSDoc links #43950

mjbvz opened this issue May 4, 2021 · 6 comments
Labels
Experience Enhancement Noncontroversial enhancements Suggestion An idea for TypeScript
Milestone

Comments

@mjbvz
Copy link
Contributor

mjbvz commented May 4, 2021

Bug Report

🔎 Search Terms

  • JSDoc
  • link / see

🕗 Version & Regression Information

4.3.0-dev.20210503

💻 Code

For some JavaScript:

// foo.js

export class Foo {}
// index.js

/**
 * {@link import('./foo').Foo Foo}
 * 
 * @param {import('./foo').Foo} foo 
 */
function withFoo(foo) { }

🙁 Actual behavior

The parameter type is resolved but the @link is not

🙂 Expected behavior

Both links should be resolved

@RyanCavanaugh RyanCavanaugh added Experience Enhancement Noncontroversial enhancements Suggestion An idea for TypeScript labels May 7, 2021
@RyanCavanaugh RyanCavanaugh added this to the Backlog milestone May 7, 2021
@olee
Copy link

olee commented Nov 15, 2021

Same issue for me - this is especially annoying, because TS and eslint regard type imports which are only used for JSDoc as unused and will request to remove those imports.

@marcelocra
Copy link

As a workaround, you could use typedef with an import, pointing the link to it:

/** @typedef {import("./typedefs.js").TheType} TheType */

/**
 * Some doc with a link to the type {@link TheType}.
 */

Not great, as "go to definition" will take you to this typedef instead of the main one, but at least the correct type is shown when hovering.

@jespertheend
Copy link
Contributor

That will cause TheType to be exported twice though (#46011). I usually just end up not linking at all in this situation, because I'd rather not have duplicate entries in my autocomplete list.

@ethanresnick
Copy link
Contributor

ethanresnick commented Nov 20, 2023

I would really love to see this too.

  • Linking to other symbols in JSDoc comments is super useful, but adding the import type at the top-level (to get jump-to-definition for that symbol) triggers eslint's no-unused-var rule.

  • Using the no-undefined-types rule from eslint-plugin-jsdoc can solve that (it'll mark the import as used for Eslint), but that rule creates the risk of a non-type-only import that's only used in a JSDoc comment being marked as used, which could lead to unnecessary/unexpected side effects in the verbatimModuleSyntax world.

  • Typescript's organizeImports language feature will automatically remove the import, even if it's referenced in a JSDoc comment.

Today, I think the best solution is to manually alias the import to start with an _, and configure eslint to not flag variables as unused if they start with an _, but that aliasing is kinda annoying. The import will also still get removed by TS' organizeImports even with the alias.

@optyler
Copy link

optyler commented Dec 5, 2023

I think my old issue is similar to this one...

I was trying to @link a function from an imported module from node_module

Per jsdoc documentation this should be possible

Link to a module (e.g. within a @link or @see tag) using "module:moduleName". For example, "@module foo/bar" can be linked to using "{@link module:foo/bar}".

I was expecting that these comments link to the function in node_module/date-fns/format but they just render as is

/**
  * @see module:date-fns/format
  * @link module:date-fns/format
  */
image

@kravetsone
Copy link

+1

Why i should import it in top of the module for simple JSDoc link?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Experience Enhancement Noncontroversial enhancements Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

8 participants