You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When running Typedoc on the following declaration file, I expect that the setter has void as return type.
/**
* The Foo class
*/
declare class Foo {
private _bar;
/**
* The bar method
* @return something
*/
get bar(): string;
/**
* The setter for the bar method
* @param bar
*/
set bar(bar: string);
}
export { Foo };
Actual Behavior
The generated documentation says that the setter has any as return type.
Note that it works as expected when using a .ts file instead of the corresponding .d.ts file. Looking at the Typedoc code base, there are tests that cover the .ts scenario but none for the .d.ts case.
Not sure if this is a Typedoc issue or rather a problem with Typescript itself. My attempt at debugging this problem gave me the idea that the Typescript compiler returns a different return type for both cases.
Environment
Typedoc version: typedoc@0.16.10
Node.js version: v12.11.1
OS: Ubuntu
The text was updated successfully, but these errors were encountered:
No, Typescript gives an error when you try to define a return type for a setter.
That's why I felt confident in adjusting my custom theme to simply hardcode void as return type for setters.
Expected Behavior
When running Typedoc on the following declaration file, I expect that the setter has
void
as return type.Actual Behavior
The generated documentation says that the setter has
any
as return type.This is also visible in the json:
Steps to reproduce the bug
Run Typedoc on the declaration file mentioned above using
The setter will have
any
as return type.Note that it works as expected when using a
.ts
file instead of the corresponding.d.ts
file. Looking at the Typedoc code base, there are tests that cover the.ts
scenario but none for the.d.ts
case.Not sure if this is a Typedoc issue or rather a problem with Typescript itself. My attempt at debugging this problem gave me the idea that the Typescript compiler returns a different return type for both cases.
Environment
The text was updated successfully, but these errors were encountered: