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

TypeScript utility types are not processed #1509

Closed
cape-dev opened this issue Feb 16, 2021 · 6 comments
Closed

TypeScript utility types are not processed #1509

cape-dev opened this issue Feb 16, 2021 · 6 comments
Labels
bug Functionality does not match expectation

Comments

@cape-dev
Copy link

cape-dev commented Feb 16, 2021

Search terms

utility types, Partial

Expected Behavior

Extending the interface Foo with Partial<Foo> should cause all properties in Bar to be optional.

Actual Behavior

Typedoc successfully extends the interface Foo and shows the properties in Bar but they are required instead of optional.

Steps to reproduce the bug

Minimal repo:
https://github.com/kamekazemaster/typedoc-utility-types-demo

Basically boils down to the following:

export interface Foo {
  foo: number;
  bar: string;
}

export interface Bar extends Partial<Foo> {}

I have already done some digging in the source code and I think it has something to do with how the reflections are modeled. I didn't have the time to dig in deeper but the ImplementsPlugin checks in the analyzeInheritance function if the reflection is instanceof DeclarationReflection. While debugging type.reflection returns undefined in the case of extending Partial<Foo>. In the case of just extending Foo it returns a DeclarationReflection.

Even though I made this observation, it seems not logical because the actual documentation includes the extended properties from Foo.

Any help on this is appreciated.

Environment

  • Typedoc version: 0.20.25
  • TypeScript version: 4.1.3
  • Node.js version: 14.15.3
  • OS: macOS Catalina
@cape-dev cape-dev added the bug Functionality does not match expectation label Feb 16, 2021
@Gerrit0
Copy link
Collaborator

Gerrit0 commented Feb 18, 2021

This happens because right now TypeDoc determines optionality based on if the member's declaration has a questionToken. I think we should be able to fix this by instead checking symbol.flags & ts.SymbolFlags.Optional. I should be able to take a closer look this weekend.

reflection.setFlag(
ReflectionFlag.Optional,
!!(declaration as any).questionToken
);

@cape-dev
Copy link
Author

Thanks! That would incredibly boost our workflow with the generated docs!

@can-pekesen
Copy link

@Gerrit0 After some further digging (tried your suggestion) I noticed, that the derived interface's property apparently also gets assigned the original declaration when debugging the setModifiers function. So the flags under declaration.symbol.flags are the same.

Maybe thats useful for you when you have a look on it.

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Feb 20, 2021

Checking the symbol flags works for optional - but fails for readonly... unfortunately I've been unable to find a non-@internal solution for picking that up.

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Feb 20, 2021

Fix released in 0.20.26 :)

@cape-dev
Copy link
Author

@Gerrit0 Thank you so much for the quick fix! Our workflow with the docs just got incredibly boosted.

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