Better documetation of Overloading types

[adamjosefus]

Problem

If you are using overloading type in your functions/methods, the builder documentation is not really helpful in this task.

Code Example A:

type Entry =
    | [title: string, content: string, button: string]
    | [title: string, content: string, button: string, options: Options]
    | [title: string, content: string, primary: string, secondary: string, options: Options];

function myFunction(...entry: Entry): void {
    // Some code...
}

VS Code intellisense:

Code Example B:

function myFunction(param1: string): void;
function myFunction(param1: number, param2: boolean): void;

function myFunction(param1: string | number, param2?: boolean): void {
    // Some code...
}

VS Code intellisense:

Suggested Solution

• Detect type for overloading and include it next to the function.
• Render all argument possibilities

[Gerrit0]

This is going to be a tricky one I think... should be possible, but by no means trivial.

[Gerrit0]

The language service is entirely too magical... and inconsistent. When hovering over the function, it shows "real" overloads...

But when providing arguments, it instead shows "signatures"

I think I'm actually going to punt this to plugin-space. I'm really wary of including functionality in TypeDoc itself which significantly changes what you'd see if looking at the declaration file of a library, since it opens up holes for questions when there's now no reference to Entry in the docs for myFunction, or myFunction is rendered with Entry and then also with the expanded signatures (ew, makes it looks like there's an extra overload...)

I might consider this if someone builds a plugin which does this that solves these issues in the rendered docs, but I'm not seeing a clean way of doing it.

---

If looking to implement this without solving that issue, I'd recommend listening to Converter.EVENT_CREATE_SIGNATURE and replacing sig.parent.signatures with the appropriately expanded signatures. I've just updated the emit for that event to also include the signature, which will be necessary to easily resolve parameter types.