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 references go to incorrect class/interface #2466

Closed
myphysicslab opened this issue Dec 31, 2023 · 6 comments
Closed

link references go to incorrect class/interface #2466

myphysicslab opened this issue Dec 31, 2023 · 6 comments
Labels
bug Functionality does not match expectation

Comments

@myphysicslab
Copy link

Search terms

link reference goes to incorrect class / interface

Expected Behavior

Within markdown for a class, I expect that {@link methodName} will generate a link to that method within that class, not a link to a sub-class.

Actual Behavior

Within markdown for a class, {@link methodName} generates a link to a sub-class, not to the current class.

Steps to reproduce the bug

I've created a pull request a0aa658 with a minimal set of files that show the bug.

I didn't understand how to modify run.sh, so that won't work. I don't have yarn on my macOS system.

I installed typedoc with npm install typedoc and then I invoke typedoc with

    ./node_modules/typedoc/bin/typedoc 

(I was also able to compile with typescript, the .js files wind up in a separate build directory)

I have 4 very simple classes (actually 3 would probably be sufficient). The hierarchy is

BugAbstractSubject < BugRigidBodySim < BugImpulseSim < BugContactSim

So BugAbstractSubject is the base class.

The problem is visible in the docs for Class BugRigidBodySim. In the description at the top of the class docs, you will see "Adds method getRigidBodySim". If you hover your pointer over the link you should see that it links to the descendent class BugContactSim. It should link to the method on the same page of BugRigidBodySim.

You will see similar problems in the third subclass BugImpulseSim.

This doesn't happen in the base class. On the docs page for BugAbstractSubject, this problem isn't happening. In the text "Has method getAbstractSubject" the link is to the same page, as expected.

Caveat:

I discovered that changing the entryPoints in typedoc.json makes this bug disappear.

The bug occurs when typedoc.json contains

    "entryPoints": ["./src"],

The bug does NOT occur with

    "entryPoints": ["./src/BugAbstractSubject.ts",
         "./src/BugRigidBodySim.ts",
         "./src/BugImpulseSim.ts",
         "./src/BugContactSim.ts"
     ],

I tried to read the docs about entryPoints and entryPointStrategy but I wasn't able to understand why this would affect the linking behavior.

Environment

TypeDoc 0.25.4
Using TypeScript 5.3.3 from ./node_modules/typescript/lib
macOS Ventura 13.6.1
node --version
v18.16.1

@myphysicslab myphysicslab added the bug Functionality does not match expectation label Dec 31, 2023
@Gerrit0
Copy link
Collaborator

Gerrit0 commented Dec 31, 2023

You win the weirdest bug of the year prize... what on earth... changing the entryPoints should in no way affect this, and I have absolutely no idea what's going on here.

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Dec 31, 2023

Entry points is (kind of) a red herring, it's conversion order.

  "entryPoints": ["./src/BugImpulseSim.ts", "./src/BugRigidBodySim.ts"], // bug 
  //   "entryPoints": ["./src/BugRigidBodySim.ts", "./src/BugImpulseSim.ts"], // no bug

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Dec 31, 2023

Minimal repro:

export interface BugImpulseSim extends BugRigidBodySim {}

/**
 * Adds method {@link getRigidBodySim} aka {@link BugRigidBodySim.getRigidBodySim}
 */
export interface BugRigidBodySim {
  getRigidBodySim(): string;
}

Switching the order the interfaces are declared in switches which interface the first @link tag goes to

@myphysicslab
Copy link
Author

Is there a solution? Are you saying I should change my code somehow (to interfaces?). I have 6 other places with similar problems, but this was the easiest one to write up.

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Jan 1, 2024

65c83a9 fixed it, and has been released

@myphysicslab
Copy link
Author

Thanks, it fixes the other 6 places as well.

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

2 participants