In the extendedTypes of Props2 I get something similar to the below, but there is no id: 88 in the generated JSON.
"extendedTypes": [{
"type": "reflection",
"declaration": {
"id": 88,
"name": "__type",
"kind": 65536,
"kindString": "Type literal",
"flags": {},
"sources": [{
"fileName": "fileName",
"line": 14,
"character": 43
}]
}
}],
I get only c:number as props in Props2.
Props2 to have a: string, b: string and c: number as its interface.
export interface Prop1 {
a: string;
b: string;
c: string;
}
export interface Prop2 extends Omit<Prop1, "c"> {
c: number;
}
typedoc --out typedoc ./file.tsx --theme minimal --mode modules
@aciccarello what are your thoughts on this bug?
This is a weird bug... There appears to be a couple issues:
extends will only occur with a type reference, which Omit<Prop1, 'c'> is not. Fixing this should at least allow "Type literal" to appear in the hierarchy section of the docs.extend clauses are incorrectly converted - it is missing information about the type, not sure why this is. Unfortunately type aliases are rather like C's macros. They are resolved incredibly early in the compilation process and are difficult to detect & extract information about.https://github.com/vkefallinos/typedoc/commit/ef812b111e4f6f45e8aaf1f51e62313d2b5265ab
I did a rough implementation to add Omit handling. It works but this code can't be merged by any means.
I figured I'd chime in with my experience with this issue.
I have a series of interfaces that extends Omit<> interfaces in the dom TypeScript library:
export interface PublicKeyCredentialUserEntityJSON extends Omit <
PublicKeyCredentialUserEntity, 'id'
> {
id: Base64URLString;
}
Here's PublicKeyCredentialUserEntity in node_modules/typescript/lib/lib.dom.d.ts:
interface PublicKeyCredentialUserEntity extends PublicKeyCredentialEntity {
displayName: string;
id: BufferSource;
}
The resulting documentation for this interface fails to list any information about PublicKeyCredentialUserEntity, instead showing an empty object:

I get the exact same output as @MasterKale but using Pick, also on 0.17.0-3.
While I know next to nothing about the internal code of typedoc, I have noticed (I believe is in the theme stage) that if you extend an interface which is not exported, the theme has nothing to link inherited members from and instead list them inherited from itself. For instance:
interface Foo {
one: number;
two: number;
}
export interface Bar extends Foo {
three: string;
}
Typedoc creates a bar.html page for the Bar interface, but not for Foo which isn't exported. The HTML displays the inherited property one, but says it is inherited from Bar itself which is clearly incorrect, but is understandable why it's doing that since there's no HTML file to link Foo.one.

Regarding the Pick and Omit issue, my best guess is that since Bar extends Pick<Foo, 'one'>effectively generates an anonymous object that isn't kept track of during the plugin reflection resolving stage, it never even adds the properties to the objects that get passed off to the theme.
However, it gets more interesting when you get the same result if inheriting from an exported type. Types don't get their own pages, but they should be kept track of in the reflection resolving stages, so while the inheritance tree is understandable, it's very confusing why we're not even seeing the inherited members.
interface Foo {
one: number;
two: number;
}
export type FooPicked = Pick<Foo, 'one'>;
export interface Bar extends FooPicked {
three: string;
}

The library mode support for inheritance is being tracked in #1386, I'll be looking at that next week, and hopefully end up with something that produces reasonable results. I'm pretty sure TypeDoc's inheritance support was written before you could inherit from types, so it was never considered.
This works properly in 0.20 - took a bit more than a week.. but worth the time spent understanding it all.

Most helpful comment
This is a weird bug... There appears to be a couple issues:
extendswill only occur with a type reference, whichOmit<Prop1, 'c'>is not. Fixing this should at least allow "Type literal" to appear in the hierarchy section of the docs.extendclauses are incorrectly converted - it is missing information about the type, not sure why this is. Unfortunately type aliases are rather like C's macros. They are resolved incredibly early in the compilation process and are difficult to detect & extract information about.