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

exported generic types do not resolve their type parameters #156

Closed
sidharthv opened this issue Nov 20, 2015 · 5 comments
Closed

exported generic types do not resolve their type parameters #156

sidharthv opened this issue Nov 20, 2015 · 5 comments
Labels
enhancement Improved functionality

Comments

@sidharthv
Copy link

For the below example:

declare interface Person {
    name: string;
}
declare type Z<T extends Person> = T & {
    address: string;
}   
declare interface IExample {
    someProperty: Z<Person>
}

The documentation shows:

someProperty: Z

and

Z: T & { address: string; }

How do I get it to show:

someProperty: Z<Person>

and something like:

Z: T & { address: string; }
T: Person
@sebastian-lenz sebastian-lenz added the enhancement Improved functionality label Dec 8, 2015
@sebastian-lenz
Copy link
Member

Hi, thank you for your message. Type aliases are quite difficult to document as the compiler resolves them very early in the process so TypeDoc has to follow some thin hints to resolve them. I'll add this as an enhancement and will try to check back on it if I find the time.

@sidharthv
Copy link
Author

Great, thanks!

Date: Tue, 8 Dec 2015 11:41:50 -0800
From: notifications@github.com
To: typedoc@noreply.github.com
CC: sidharthv@outlook.com
Subject: Re: [typedoc] exported generic types do not resolve their type parameters (#156)

Hi, thank you for your message. Type aliases are quite difficult to document as the compiler resolves them very early in the process so TypeDoc has to follow some thin hints to resolve them. I'll add this as an enhancement and will try to check back on it if I find the time.


Reply to this email directly or view it on GitHub.

@Schniz
Copy link

Schniz commented Mar 13, 2019

Hey!
First of all, mad props about the product. This project is veryyyyyy good and produces high quality stuff! I'm impressed!

I wonder if the ~3 years that have passed have changed something in it in terms of TypeScript tooling? The following code has conditional types in it, but the TS server types it correctly; however, TypeDoc wouldn't "resolve" the type.

image

This type is hand-rolled, but you can easily see how a Pick type (that comes with TypeScript) will act the same way on TS server and TypeDoc:

image

It is something that can be done? Is it something you are willing to support?
I believe that would make the docs much more verbose, but easier to read

@sammoore
Copy link

sammoore commented Aug 14, 2020

Came here looking for support for Pick -- I have an interface like such (re-typed, no promise of 0 typos 😄):

export interface RTPMediaExtensions extends Pick<RTCPeerConnection,
  | 'getSenders'
  | 'getReceivers'
  | 'getTransceivers'
  | 'addTrack'
  | 'removeTrack'
  | 'addTransceiver'
  | 'addEventListener'
  | 'removeEventListener'
  | 'ontrack'
> {}

With "Inherited" on, I am looking for the Interface's documentation to show these picked properties -- but instead it's an empty interface in typedoc's output. Not sure where to start looking in TypeDoc for solving this though.

sammoore added a commit to paradigmpost/rtcpeer that referenced this issue Aug 14, 2020
… previously Pick<>'d for better TypeDoc support:

See TypeStrong/typedoc#156 (comment) for more information.
sammoore added a commit to paradigmpost/rtcpeer that referenced this issue Aug 14, 2020
… previously Pick<>'d for better TypeDoc support:

See TypeStrong/typedoc#156 (comment) for more information.
@Gerrit0
Copy link
Collaborator

Gerrit0 commented Nov 29, 2020

Closing in favor of #1386 - this is fixed in 0.20.

@Gerrit0 Gerrit0 closed this as completed Nov 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improved functionality
Projects
None yet
Development

No branches or pull requests

5 participants