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

hyperlink not generated for {@link type#property} #732

Open
techfg opened this issue Dec 7, 2024 · 3 comments
Open

hyperlink not generated for {@link type#property} #732

techfg opened this issue Dec 7, 2024 · 3 comments
Labels
bug Issue raised as a bug. fixed Fix implemented in latest version.

Comments

@techfg
Copy link

techfg commented Dec 7, 2024

What package is the bug related to?

typedoc-plugin-markdown

Describe the issue

When using @link to reference a type property, the generated markdown is not hyperlinked.

Repro: https://stackblitz.com/edit/vitejs-vite-rq6ycbce

export type Foo = { name: string };

/**
 * Foo Handler that takes {@link Foo} and uses {@link Foo#name name}
 */
export const handleFoo = (a: Foo) => {};

Steps to Reproduce

  1. Open repro
  2. npm run docs:md
  3. View docs-md/functions/handleFoo.md

Actual Result
Generated markdown does not hyperlink the name property:

image

# Function: handleFoo()

> **handleFoo**(`a`): `void`

Foo Handler that takes [Foo](../type-aliases/Foo.md) and uses name

Additional Information

  1. The issue does not occur when generating html files (npm run docs:html)
  2. The type Foo itself does get hyperlinked
  3. I tried applying useHTMLAnchors=true but this did not result in name being hyperlinked either. In fact, there didn't seem to be any anchor elements generated at all - possibly I'm misunderstanding useHTMLAnchors or this may be a separate bug/issue?

TypeDoc configuration

typedoc: 0.27.3
typedoc-plugin-markdown: 4.3.1
typescript: 5.7.2

Expected behavior

The property name should be hyperlinked.

@techfg techfg added the bug Issue raised as a bug. label Dec 7, 2024
@tgreyuk
Copy link
Member

tgreyuk commented Dec 8, 2024

Thanks - links on props are now resolved in [email protected]. You would only need to set useHTMLAnchors=true when the property is included inside a table (without associated heading anchor).

@tgreyuk tgreyuk added the fixed Fix implemented in latest version. label Dec 8, 2024
@techfg
Copy link
Author

techfg commented Dec 8, 2024

Thanks for the quick fix @tgreyuk and appreciate the clarification on usage of useHTMLAnchors!

Types are looking good with this fix but there is a strange issue with interfaces.

Repro: https://stackblitz.com/edit/vitejs-vite-zdmljw8o

When using typeDeclarationFormat='table' a link is generated for interface#property but it does not contain the property fragment in the url. This does not happen when typeDeclarationFormat is set to list or htmlTable. When adding useHTMLAnchors, the problem does not occur but since I don't believe typeDeclarationFormat has anything to do with interfaces, I would expect the interface link to generate correctly without requiring useHTMLAnchors, correct?

  • Using list or htmlTable (use npm run docs:md) - Expected
    image

  • Using table (use npm run docs:md2) - Not Expected
    image

  • Using table and useHTMLAnchors (use npm run docs:md3) - Expected
    image

@tgreyuk
Copy link
Member

tgreyuk commented Dec 8, 2024

but since I don't believe typeDeclarationFormat has anything to do with interfaces, I would expect the interface link to generate correctly without requiring useHTMLAnchors, correct?

You are absolutely correct, this isn't quite correct. The idea is that when an anchor cannot be resolved it fallsback to the nearest available anchor, but like you say the interface anchors should not be effected by the options you have set. Also foo.md#__type is not a correct fallback.

Thanks again - ill be fixed in next patch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue raised as a bug. fixed Fix implemented in latest version.
Projects
None yet
Development

No branches or pull requests

2 participants