chore: fix invalid tsdoc tags in comments #2836
Conversation
- Invalid block tags prevent api-documenter from generating apidocs
| * - projectRoot: Root of project. All other artifacts are resolved relative to this | ||
| * - booters: An array of booters to bind to the application before running bootstrapper | ||
| * - filter.booters: An array of booters that should be run by the bootstrapper | ||
| * - filter.phases: An array of phases that should be run |
There was a problem hiding this comment.
This documentation does not match the described interface.
I believe booters and filters properties were moved from BootOptions to BootExecutionOptions; and projectRoot was moved to Bootable interface.
There was a problem hiding this comment.
This can be fixed in a follow-up PR. The original doc follows js style. For TS, such properties should be documented directly at BootExecutionOptions and Bootable level.
| * - extensions: File extensions to look for to match an artifact (this is a convention based booter) | ||
| * - glob: Glob pattern to use to discover artifacts. Takes precedence over (dirs + extensions) | ||
| * - discovered: List of files discovered by the Booter that matched artifact requirements | ||
| * - classes: List of exported classes discovered in the files |
There was a problem hiding this comment.
Describing properties in class documentation is weird. Can you move the documentation of individual properties to property-level tsdoc comments please?
| @@ -10,7 +10,7 @@ import {SchemaObject} from '@loopback/openapi-v3-types'; | |||
| * parameter's type. | |||
| * `type` and `format` will be preserved if provided in `schema` | |||
| * | |||
| * @private | |||
| * @internal | |||
There was a problem hiding this comment.
Does strong-docs recognize @internal annotation? If not, then I think this change is going to break API docs that we are generating right now :(
| @@ -14,10 +14,10 @@ import {Class} from './common-types'; | |||
| * the actual reference to the class itself until later, when both sides | |||
| * of the relation are created as JavaScript classes. | |||
| * | |||
| * @template Type The type we are resolving, for example `Entity` or `Product`. | |||
| * @typeparam Type The type we are resolving, for example `Entity` or `Product`. | |||
There was a problem hiding this comment.
Does strong-docs recognize @typeparam annotation? If not, then I think this change is going to break API docs that we are generating right now :(
There was a problem hiding this comment.
TypeDoc already uses @typeparam - https://github.com/TypeStrong/typedoc/blob/0014556908f807486d2c1d17812ed472113fe522/examples/basic/src/generics.ts#L4
|
To be assured, |
Invalid block tags prevent api-documenter from generating apidocs.
Relates to #2834
Checklist
👉 Read and sign the CLA (Contributor License Agreement) 👈
npm testpasses on your machinepackages/cliwere updatedexamples/*were updated👉 Check out how to submit a PR 👈