Skip to content

JsDoc for overloads #3294

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

Closed
danmarshall opened this issue May 28, 2015 · 3 comments
Closed

JsDoc for overloads #3294

danmarshall opened this issue May 28, 2015 · 3 comments
Labels
By Design Deprecated - use "Working as Intended" or "Design Limitation" instead

Comments

@danmarshall
Copy link

When adding JSDoc to an overloaded function, It seems that the JSDoc comment must immediately precede the actual function. When preceding the list of overloads, the JSDoc comment is dropped after compilation.

Example:

module app {

/**
 * Returns "foo"
 * 
 * this doesn't output.
 */
export function foo(x: string): string;
export function foo(x: number): string;
export function foo(x: any): string {
    return "foo";
}


export function bar(x: string): string;
export function bar(x: number): string;

/**
 * Returns "bar"
 * 
 * this will output. but I don't like my overloads detached.
 */
export function bar(x: any): string {
    return "bar";
}

}

@mhegazy mhegazy added Suggestion An idea for TypeScript By Design Deprecated - use "Working as Intended" or "Design Limitation" instead and removed Suggestion An idea for TypeScript labels May 28, 2015
@mhegazy
Copy link
Contributor

mhegazy commented May 28, 2015

Overloads do not get emitted, similar to interfaces; they are only used for compile time checks but do not exist at runtime. Only the function implementation exists. the problem is what happens if you have multiple comments, e.g. one per signature. duplicating does not seem ideal. more over, if the comments were aggregated, there is no way for you to document an overload with different information than the implementation (e.g. to show in .d.ts but not in the .js file).

@danmarshall
Copy link
Author

I concur. Perhaps the JsDoc subfeature needs its own documentation page. Would be nice to share this knowledge instead of having to learn by surprise. Thanks :)

@mhegazy
Copy link
Contributor

mhegazy commented May 29, 2015

The general rule is that comments follow a language construct; if that ends up emitted the comment will be emitted, otherwise not. This applies to the .js and .d.ts emit as well.

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
By Design Deprecated - use "Working as Intended" or "Design Limitation" instead
Projects
None yet
Development

No branches or pull requests

2 participants