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

Link text doesn't become a link when using {@link X | Y} #1302

Closed
StoneT2000 opened this issue May 13, 2020 · 9 comments
Closed

Link text doesn't become a link when using {@link X | Y} #1302

StoneT2000 opened this issue May 13, 2020 · 9 comments
Labels
bug Functionality does not match expectation

Comments

@StoneT2000
Copy link

Search terms

link, link text

Expected Behavior

Something such as {@link MyClass | some other text} should show up as a link to MyClass but the text is "some other text"

Actual Behavior

Instead, the documentation just shows "{@link MyClass | some other text}" literally, not parsed.

Steps to reproduce the bug

The repo I'm working on https://github.com/stonet2000/dimensions

Just adding {@link MyClass | some other text} over a class and running the following command:

typedoc --theme ./theme/dimensions/ --mode modules --exclude ./src/Station/ --out docs ./src && touch ./docs/.nojekyll

My typedoc.json:

{
  "inputFiles": ["./src"],
  "mode": "modules",
  "out": "docs",
  "theme": "./theme/dimensions",
  "tsconfig": "./tsconfig.json",
  "exclude": ["./src/Station/**/*"],
  "target": "es5"
}

(I realize that I don't need all of those command line args)
My tsconfig.json

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "outDir": "lib/",
    "sourceMap": true,
    "declaration": true,
    "allowJs": true,
    "esModuleInterop": true,
    "isolatedModules": true
  },
  "include": [
    "src/**/*"
  ],
  "exclude": [
    "node_modules",
    "docs",
    "lib",
    "examples",
    "templates",
    "src/Station/web/**/*",
    "src/Station/local/**/*"
  ]
}

Environment

  • Typedoc version: typedoc@0.17.6
  • TypeScript version: 3.8.3
  • Node.js version: 12.16.1
  • OS: MacOS 10.13.6, High Sierra
@StoneT2000 StoneT2000 added the bug Functionality does not match expectation label May 13, 2020
@mjackson
Copy link

I can't seem to get {@link Foo} working at all, @StoneT2000. Even without the extra text after the |.

I looked through your repo and noticed that you have a few regular {@link} tags w/out the extra text. Are those working ok for you? Or is it only the ones with the | and the extra text?

@StoneT2000
Copy link
Author

StoneT2000 commented May 13, 2020

Oh sorry I gave a hypothetical example. Foo isn't a class or type or anything so it shouldn't work anyway?

In my repo, an example of a working {@link} tag is {@link Design} or {@link Agent}. Those definitely work. But suppose I wanted to write Agents and wanted that to link to the agent class, I tried {@link Agent | Agents} but that doesn't work. Thanks for the fast reply btw!

@Gerrit0
Copy link
Collaborator

Gerrit0 commented May 15, 2020

Fixed with 935e10a, should hopefully have a release later today, or at least by the end of the weekend.

@Gerrit0
Copy link
Collaborator

Gerrit0 commented May 15, 2020

@mjackson I just created https://typedoc.org/guides/link-resolution/, which should hopefully answer your question. If it doesn't, feel free to create a new issue

@StoneT2000
Copy link
Author

That's actually pretty clear! However, I did notice that in the commit 935310a, there was a comment that used "classes".NameInterface. It would be great if there's documentation on how to reference a symbol across different paths explicitly if that's possible

@Gerrit0
Copy link
Collaborator

Gerrit0 commented May 15, 2020

I think the doc page linked above covers that, did I miss something?

@StoneT2000
Copy link
Author

Maybe i missed it but i can’t find documentation about using the “” quotes to specify a file path directly to where we want to have typedoc search for symbols first

@Gerrit0
Copy link
Collaborator

Gerrit0 commented May 15, 2020

Looks like you're right, I thought I mentioned it. Adding this under the structure block:

This structure can be used to determine the fully qualified name of each
reflection. The fully qualified name of a reflection is the name of the
reflection and all its parents, joined with .; that is, the fully qualified
name of the seeds property is "index".Apple.seeds. You can use the fully
qualified name to link to symbols defined in other source files without relying
on the slow fourth step of the algorithm used to resolve links.

@Gerrit0
Copy link
Collaborator

Gerrit0 commented May 17, 2020

v0.17.7 released with this :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Functionality does not match expectation
Projects
None yet
Development

No branches or pull requests

3 participants