swagger-api / swagger-api/swagger-codegen
[JS] jsdoc - duplication of entries as both modules and classes (etc)
Nobody has claimed this yet.
- Dominant language
- Mustache
- Stars
- 17.8k
- Forks
- 6k
- PR merge metrics
- No merged PRs in 30d
Description
A few more issues with the jsdoc annotations in the JS client.
- If I generate jsdoc from the petstore sample using this command in the javascript petstore dir,
jsdoc -r src -d jsdoc -R README.md
I end up with this:
The problem I want to point out is that the entries under "classes" and "modules" are duplicated, with one exception: "index" appears only under "modules". I propose that we get rid of the "module" entries, except for "index". This is easily achieved by getting rid of this module-level comment block in partial_model_generic.mustasche:
/**
* The {{classname}} model module.
* @module {{#invokerPackage}}{{invokerPackage}}/{{/invokerPackage}}{{#modelPackage}}{{modelPackage}}/{{/modelPackage}}{{classname}}
* @version {{projectVersion}}
*/
module/andapi/in classnames -- All the class entries havemodule/orapi/in them, for example,api/FakeApi,model/Client, corresponding to the directories in which they are found. But these "package" components are not used when you actually instantiate the classes. The intended usage is shown in the "Home" page (from README.md):
All the API and model classes are direct members of the top-level module (the aforementioned index), so the api/ and model/ parts are never used. This point goes along with point (1) above. If we wanted to use the model/api classes directly, and not via the top-level module, then we would need to use the path components. But as it stands, this will be confusing for the user.
- Duplication of information in the "Home" and "index" pages. Both of these describe how to use the client, but using somewhat different content. Both have pros and cons, and we should combine both to one page that has the best parts of both.
I like the "Members" section in "index", and it can replace the "Documentation for API endpoints" and "Documentation for Models" in "Home". On the other hand, "Home" has better installation/getting started instructions, and includes authentication details.
- Weird "module:" issues. For example, this view is very confusing,
especially given that the constructor command they give doesn't actually work. I would like to see here:
Class: FakeApi
FakeApi
new FakeApi(apiClient)
This is still a bit redundant in the first two lines, but that's more of an issue with jsdoc itself.
Alternatively, for the constructor command: new module.FakeApi(apiClient), if we take module to be the name used for the top-level index module in the require command.
Similarly with all the links, i.e. instead of module:ApiClient, just ApiClient. Alternatively, module.ApiClient. Perhaps this would take care of itself if (1) and (2) are fixed.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in the JavaScript petstore output using jsdoc -r src -d jsdoc -R README.md, then inspect partial_model_generic.mustasche and compare the generated Home and index pages. Done means removing duplicate module entries except index, avoiding unused api/ and model/ name components, consolidating the Home and index content, and making constructor and links consistent with the documented usage.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100