Skip to content
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

Top level module level comments don't show if imports exist #603

Closed
nickzelei opened this issue Sep 27, 2017 · 17 comments
Closed

Top level module level comments don't show if imports exist #603

nickzelei opened this issue Sep 27, 2017 · 17 comments

Comments

@nickzelei
Copy link
Contributor

nickzelei commented Sep 27, 2017

It seems that top level module level comments don't appear if the module also has imports.

/**
* @copyright <our copyright here>
*/

import * as _ from "lodash";

I have tested this in files that do have imports vs files that don't. The top level module comment only appears in modules that do not have any external imports.

@aciccarello
Copy link
Collaborator

I'm curious if it thinks the comment is for the import.

Does the module comment appear if you do the following?

/**
* @copyright <our copyright here>
*/

/** ignore this comment */
import * as _ from "lodash";

@nickzelei
Copy link
Contributor Author

Yes, that did make it appear.

@nickzelei
Copy link
Contributor Author

It only appeared when using the multi-line notation. It did not change when using single line.

@chriskrycho
Copy link

At least for me, it works if using a single-line comment in front of the imports.

@christopherthielen
Copy link
Contributor

I'm not sure what the intention is behind the code, but this is due to these lines: https://github.com/TypeStrong/typedoc/blob/v0.9.0/src/lib/converter/factories/comment.ts#L90-L93

@nickzelei
Copy link
Contributor Author

nickzelei commented Nov 8, 2017

That looks like the culprit. Single-line comments are not ideal (at least for us) since they are used as file headers..so they are naturally multi-line.

Any comment type should be supported.

@demurgos
Copy link

demurgos commented Apr 6, 2018

I am encountering the same issue. I also use the workaround described above (using a dummy doc comment).
It would be nice if the lines highlighted by @christopherthielen were either removed or explained.

@ShawnTalbert
Copy link

I'm trying out TypeDoc and can't seem to get a top level module description to render.

The top of my module file looks like so:

/**
 * Document all the things
 */


//imports
import {Result} from "N/search"

Any ideas? I think this is a great project but if I can't have introductory text at the top of a module if feels rather raw.

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Feb 9, 2019

//imports won't be caught as a documentation comment. Change it to /** imports */ and you should be golden.

@ShawnTalbert
Copy link

Thanks @Gerrit0 switching to that style of comment (specifically with two prefix asterisks) worked. This is a very annoying bug.

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Feb 11, 2019

It is not a bug. TypeScript doesn't have the concept of a "module" documentation comment, and will take the concatenation of all doc comments before a declaration.

Given the following file:

/** Module */

/** Function */
export function test () {}

TypeScript will give "Module Function" as the documentation for test.

image

TypeDoc follows the JSDoc behavior of only treating the last comment as the documentation, so only "Function" would be included in the documentation. This makes it possible for a module comment to exist - if it is separated from any node by another documentation comment. This behavior is documented on the site.

While we could introduce a bunch of checks to say that some node types "can't" be documented, this would open the door to more breaking changes in the future, and I don't think it's a good idea right now.

@aciccarello
Copy link
Collaborator

@Gerrit0 Thanks for pointing out the TypeScript parsing.

This is a difficult problem to solve without breaking changes. There are many different cases we would need to handle if we were trying not to be too restrictive. The simplest semantics I can think of is that file documentation would need to be at the very beginning of the file and be followed by a empty line. Another option would be to require something like a @file comment tag, though I don't love that idea.

I'd like to see some clarification on microsoft/tsdoc#6 before making a breaking change.

File with imports

/**
 * This clearly is at the top of the file. Imports are never documented.
 */
import foo from 'foo';

export function bar() {
  foo();
}

File comment that isn't first line

/*
 * Corporate header
 * @copyright Foo Inc.
 */
/**
 * I'm not sure how important this use case is but it may be worth recognizing.
 */

export function bar() {
  foo();
}

File without imports

/**
 * The only indication that this is a file level comment is the empty line.
 */

export function foo() {
  return 'foo';
}

export function bar() {
  return 'bar';
}

Commented out lines

/**
 * This clearly is at the top of the file. Imports are never documented.
 */
// import foo from 'foo';

export function bar() {
  // foo();
}
/**
 * This could have been a comment for the following line that was commented out.
 */
// const foo = () => 'foo';

export function bar() {
  foo();
}

@ShawnTalbert
Copy link

I sympathize with limitations of TS under the covers. However a full featured API documentation tool like TypeDoc should consider top level module documentation as a first-class feature one way or another.

I've seen far too many APIs documented that just dump you into a haphazard collection of exported symbols. The top-level documentation provides context to tie it all together and helps the reader make sense of what follows.

If I can be of any assistance I'm happy to help.

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Dec 26, 2019

With 0.15.6 (should be out later today) TypeDoc supports the @packageDocumentation tag to mark a comment as documentation for the file. This is consistent with TSDoc's effort to standardize blocks.

The legacy behavior of using a dummy comment still works, but using @packageDocumentation is preferred.

@Gerrit0 Gerrit0 closed this as completed Dec 26, 2019
raineorshine added a commit to cybersemics/em that referenced this issue Dec 5, 2020
typedoc-plugin-module-wide-comments is not compatible with typescript v4

See TypeStrong/typedoc#603 for the original issue that explains why module-level comments are not possible without an explicit @packageDocumentation.
ajacksified added a commit to inrupt/solid-client-notifications-js that referenced this issue Apr 8, 2021
Typedoc tries to render block style comments as documentation; switch to
double-slash instead. (Note: this only affects files like error which
don't have imports. TypeStrong/typedoc#603)
ajacksified added a commit to inrupt/solid-client-notifications-js that referenced this issue Apr 9, 2021
Typedoc tries to render block style comments as documentation; switch to
double-slash instead. (Note: this only affects files like error which
don't have imports. TypeStrong/typedoc#603)
@Rigii
Copy link

Rigii commented Jul 13, 2022

For me still an actual issue.
TypeDoc totally ignores top-level comments in my functional component index file.
Any imports here.
Same story if comment in a component file, and doc generates directly for it. I just started to use TypeDoc for my React project, could somebody explain what's wrong?
index.ts

/**
 * @module LogoSafeComponent
 * # This is a comment!!!
 * ## This is a comment 2!!!
 * ## This is a comment 3!!!
 * @param classNameCustom - custom styling class name
 * @param isSmall - img size
 * @module
 */

/** ignore this comment */
export * from "./LogoSafe"; 

modules.md output


[safe-app](README.md) / Exports

# some-app

## Table of contents

### Functions

- [LogoSafeComponent](modules.md#logosafecomponent)

## Functions

### LogoSafeComponent

▸ **LogoSafeComponent**(`__namedParameters`): `ReactElement`<`any`, `string` \| `JSXElementConstructor`<`any`\>\>

#### Parameters

| Name                                 | Type      |
| :----------------------------------- | :-------- |
| `__namedParameters`                  | `Object`  |
| `__namedParameters.classNameCustom?` | `string`  |
| `__namedParameters.isSmall?`         | `boolean` |

#### Returns

`ReactElement`<`any`, `string` \| `JSXElementConstructor`<`any`\>\>

#### Defined in

[LogoSafe.tsx:13](https://github.com/SomeAppOfficial/chrome-extension/blob/efc774c/src/components/LogoSafe/LogoSafe.tsx#L13)

If I highlit my component in code, the documentation looks as expected. Actually, I expect the same data in my .md output:

Screenshot 2022-07-13 at 18 36 43

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Jul 13, 2022

Please open a new issue rather than bumping a (at this point very old) one

@heyakyra
Copy link

For people who end up here via search…

The module-level comment will only work if the first declaration also has a TSDoc comment.
https://github.com/microsoft/FluidFramework/wiki/TSDoc-Guidelines#documenting-modules

There is a conflict between TypeDoc and TSDoc: matrix-org/matrix-js-sdk#3243 (comment)

And adding support for an @module tag would be good microsoft/tsdoc#296 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants