Skip to content

File-level docblocks are being treated as method level blocks #976

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
tdmalone opened this issue Dec 16, 2017 · 2 comments
Closed

File-level docblocks are being treated as method level blocks #976

tdmalone opened this issue Dec 16, 2017 · 2 comments

Comments

@tdmalone
Copy link

Input code:

/**
 * @file This is my module.
 * @author Tim Malone
 */

'use strict';

Linter output:

/index.js
  1:1  warning  could not determine @name for hierarchy

Output documentation:

## 

This is my module.

**Meta**

-   **author**: Tim Malone

What I expected to happen:

I'm trying to use the @file tag to explain the purpose of the file. It looks like Documentation is parsing this as a 'virtual comment', and is looking for @name.

(At first I thought it was expecting the name of the package, which I was expecting would be automatically inferred from the package.json).

It's possible I'm misunderstanding the purpose of the @file tag. I was hoping to get a description of the file within the documentation - or at the very least, not have the linter ask for the name of it ;).

  • What version of documentation.js are you using?: v5.3.5
  • How are you running documentation.js (on the CLI, Node.js API, Grunt, other?): CLI
@tmcw
Copy link
Member

tmcw commented Dec 19, 2017

Sorry, the @file tag isn't supported in any of the output modes at this point. It's a JSDoc feature that is implemented in the official JSDoc parser, but not yet here. Happy to review & merge a PR implementing support.

In dx-spec, we're likely dropping the @file tag because it's unclear whether source files should have any representation in documentation. Given that the recommended method of consuming JavaScript modules is from the module entry point, documenting in the public API where the methods come from has uncertain value.

@tmcw
Copy link
Member

tmcw commented Apr 12, 2018

Closing - happy to review any PR that adds @file support, tracking tags in #9

@tmcw tmcw closed this as completed Apr 12, 2018
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

2 participants