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

The "defined in" points to node_modules type rather than to actual code #2307

Closed
allista opened this issue Jun 8, 2023 · 4 comments
Closed
Labels
bug Functionality does not match expectation help wanted Contributions are especially encouraged

Comments

@allista
Copy link

allista commented Jun 8, 2023

Search terms

defined in
node_modules
react
functional component
FC

Expected Behavior

The Defined in field in generated docs should refer to the actual file where the documented function is defined, rather than the library code where its type is defined.

Actual Behavior

The doc entry for a react functional component declared in my-package/src/MyComponent.tsx as follows:

/**
* Description
* 
* @constructor
*/
export const MyComponent: FC = () => (<div>A test</div>);

Contains this Defined in section:

Defined in

node_modules/.pnpm/@[types+react@16.9.23](mailto:types+react@16.9.23)/node_modules/@types/react/index.d.ts:519

It is the same for any component defined in any module this way.

Steps to reproduce the bug

The typedoc config in tsconfig.json:

  "typedocOptions": {
    "entryPoints": ["src/index.ts"],
    "out": "docs",
    "entryDocument": "index.md"
  }

Run as typedoc --plugin typedoc-plugin-markdown

Environment

  • Typedoc version: 0.24.8
  • TypeScript version: 4.6.4
  • Node.js version: 16
  • OS: Ubuntu
  • typedoc-plugin-markdown: 3.15.3
@allista allista added the bug Functionality does not match expectation label Jun 8, 2023
@Gerrit0
Copy link
Collaborator

Gerrit0 commented Jun 25, 2023

Yet another reason to not use FC...

This happens because the signature declaration takes display priority, and the signature for that variable is defined in the types. TypeDoc should probably check here if the reflection is a signature and does not share a source declaration location with its parent, in which case it should replace its source declaration with that defined on the parent.

@Gerrit0 Gerrit0 added help wanted Contributions are especially encouraged good first issue Easier issue for first time contributors labels Jun 25, 2023
@loucyx
Copy link

loucyx commented Jul 21, 2023

I notice that it also points to the wrong place when using currying, which might be related (if not I can create a new issue):

// times.ts
const times = b => a => a * b;

// double.ts
const double = times(2);

In previous versions of TypeDoc this generated "defined in double.ts" for double.ts, but now it generates "defined in times.ts".

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Jul 22, 2023

The fix I described above should handle both of these cases

@Gerrit0 Gerrit0 removed the good first issue Easier issue for first time contributors label Aug 11, 2023
@Gerrit0
Copy link
Collaborator

Gerrit0 commented Aug 11, 2023

... well, it would, if it that didn't break in this case:

export const all: {
    <T>(fn: (item: T) => boolean, iterator: Iterable<T>): boolean;
    <T>(fn: (item: T) => boolean): (iterator: Iterable<T>) => boolean;
} = () => false as any;

This is trickier than I thought..

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 help wanted Contributions are especially encouraged
Projects
None yet
Development

No branches or pull requests

3 participants