Typedoc: TypeScript utility types are not processed

Created on 16 Feb 2021  路  6Comments  路  Source: TypeStrong/typedoc

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
bug

Most helpful comment

Fix released in 0.20.26 :)

All 6 comments

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.

https://github.com/TypeStrong/typedoc/blob/e3aa04f24253b60f77f5addab6ce364c379d4f20/src/lib/converter/symbols.ts#L908-L911

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

@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.

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.

Fix released in 0.20.26 :)

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

Was this page helpful?
0 / 5 - 0 ratings