adapt-authoring-docs 1.1.0 → 1.1.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/adapt-authoring.json +5 -3
- package/docs/jsdoc-guide.md +196 -0
- package/docs/rest-api-guide.md +291 -0
- package/docs/writing-documentation.md +37 -33
- package/docsify/styles/adapt.css +2 -1
- package/package.json +1 -1
package/adapt-authoring.json
CHANGED
|
@@ -3,9 +3,11 @@
|
|
|
3
3
|
"documentation": {
|
|
4
4
|
"enable": true,
|
|
5
5
|
"manualPages": {
|
|
6
|
-
"building-docs.md": "
|
|
7
|
-
"custom-documentation-plugins.md": "
|
|
8
|
-
"
|
|
6
|
+
"building-docs.md": "documentation",
|
|
7
|
+
"custom-documentation-plugins.md": "documentation",
|
|
8
|
+
"jsdoc-guide.md": "documentation",
|
|
9
|
+
"rest-api-guide.md": "documentation",
|
|
10
|
+
"writing-documentation.md": "documentation"
|
|
9
11
|
}
|
|
10
12
|
}
|
|
11
13
|
}
|
|
@@ -0,0 +1,196 @@
|
|
|
1
|
+
# JSDoc style guide
|
|
2
|
+
|
|
3
|
+
This guide covers the JSDoc conventions used throughout the Adapt authoring tool. Following these conventions ensures your code integrates properly with the auto-generated documentation. For comprehensive JSDoc documentation, see the [official JSDoc website](https://jsdoc.app/).
|
|
4
|
+
|
|
5
|
+
The documentation generator scans all `.js` files in `lib/` and the module's `index.js`.
|
|
6
|
+
|
|
7
|
+
## Basic structure
|
|
8
|
+
|
|
9
|
+
All exported classes, functions, and significant variables should have JSDoc comments. Comments use the `/** ... */` format:
|
|
10
|
+
|
|
11
|
+
```javascript
|
|
12
|
+
/**
|
|
13
|
+
* Brief description of what this does
|
|
14
|
+
* @memberof namespaceName
|
|
15
|
+
*/
|
|
16
|
+
class MyClass {
|
|
17
|
+
// ...
|
|
18
|
+
}
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
## Common tags reference
|
|
22
|
+
|
|
23
|
+
The below table lists the most common tags used in JSDoc comments:
|
|
24
|
+
|
|
25
|
+
| Tag | Purpose | Example |
|
|
26
|
+
| --- | ------- | ------- |
|
|
27
|
+
| `@memberof` | Assign to namespace | `@memberof core` |
|
|
28
|
+
| `@extends` | Document inheritance | `@extends {AbstractModule}` |
|
|
29
|
+
| `@type` | Property type | `@type {String}` |
|
|
30
|
+
| `@param` | Function parameter | `@param {Object} data The input data` |
|
|
31
|
+
| `@return` | Return value | `@return {Promise} Resolves with result` |
|
|
32
|
+
| `@override` | Overridden method | `@override` |
|
|
33
|
+
| `@typedef` | Custom type definition | `@typedef {Object} MyOptions` |
|
|
34
|
+
| `@property` | Property of typedef | `@property {String} name The name` |
|
|
35
|
+
| `@ignore` | Exclude from docs | `@ignore` |
|
|
36
|
+
| `@example` | Code example | `@example myFunction()` |
|
|
37
|
+
| `@see` | Cross-reference | `@see {ApiRoute}` |
|
|
38
|
+
|
|
39
|
+
## Style notes
|
|
40
|
+
|
|
41
|
+
Following [Standard.js](https://standardjs.com/) conventions:
|
|
42
|
+
|
|
43
|
+
- No semicolons in examples
|
|
44
|
+
- No trailing commas
|
|
45
|
+
- Use single quotes in code examples
|
|
46
|
+
- Two-space indentation
|
|
47
|
+
|
|
48
|
+
## Namespaces
|
|
49
|
+
|
|
50
|
+
Use `@memberof` to group related classes into namespaces. The namespace should use the name of your module (e.g. `core`, `api`).
|
|
51
|
+
|
|
52
|
+
```javascript
|
|
53
|
+
/**
|
|
54
|
+
* Core functionality
|
|
55
|
+
* @namespace core
|
|
56
|
+
*/
|
|
57
|
+
|
|
58
|
+
/**
|
|
59
|
+
* The main application class
|
|
60
|
+
* @memberof core
|
|
61
|
+
* @extends {AbstractModule}
|
|
62
|
+
*/
|
|
63
|
+
class App extends AbstractModule {
|
|
64
|
+
// ...
|
|
65
|
+
}
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
## Classes
|
|
69
|
+
|
|
70
|
+
Document classes with a brief description, namespace membership, and inheritance:
|
|
71
|
+
|
|
72
|
+
```javascript
|
|
73
|
+
/**
|
|
74
|
+
* Abstract module for creating APIs
|
|
75
|
+
* @memberof api
|
|
76
|
+
* @extends {AbstractModule}
|
|
77
|
+
*/
|
|
78
|
+
class AbstractApiModule extends AbstractModule {
|
|
79
|
+
// ...
|
|
80
|
+
}
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
## Properties
|
|
84
|
+
|
|
85
|
+
Document instance properties with `@type`.
|
|
86
|
+
|
|
87
|
+
**Important:** Any declared instance variables must be initialised to be picked up by the documentation generator. Use `undefined` if no initial value is needed.
|
|
88
|
+
|
|
89
|
+
```javascript
|
|
90
|
+
constructor () {
|
|
91
|
+
/**
|
|
92
|
+
* Reference to the main app instance
|
|
93
|
+
* @type {App}
|
|
94
|
+
*/
|
|
95
|
+
this.app = app
|
|
96
|
+
|
|
97
|
+
/**
|
|
98
|
+
* Time taken in milliseconds for module to initialise
|
|
99
|
+
* @type {Number}
|
|
100
|
+
*/
|
|
101
|
+
this.initTime = undefined // initialise even if no value yet
|
|
102
|
+
}
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
## Methods
|
|
106
|
+
|
|
107
|
+
Document methods with a description, parameters, and return values:
|
|
108
|
+
|
|
109
|
+
```javascript
|
|
110
|
+
/**
|
|
111
|
+
* Enables waiting for other modules to load
|
|
112
|
+
* @param {...String} modNames Names of modules to wait for
|
|
113
|
+
* @return {Promise} Resolves when specified module has been loaded
|
|
114
|
+
*/
|
|
115
|
+
async waitForModule (...modNames) {
|
|
116
|
+
// ...
|
|
117
|
+
}
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
For methods with complex parameters:
|
|
121
|
+
|
|
122
|
+
```javascript
|
|
123
|
+
/**
|
|
124
|
+
* Inserts a new document into the DB
|
|
125
|
+
* @param {Object} data Data to be inserted into the DB
|
|
126
|
+
* @param {InsertOptions} options Function options
|
|
127
|
+
* @param {external:MongoDBInsertOneOptions} mongoOptions Options passed to MongoDB
|
|
128
|
+
* @return {Promise} Resolves with DB data
|
|
129
|
+
*/
|
|
130
|
+
async insert (data, options = {}, mongoOptions = {}) {
|
|
131
|
+
// ...
|
|
132
|
+
}
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
## Overridden methods
|
|
136
|
+
|
|
137
|
+
Use `@override` for methods that override a parent class:
|
|
138
|
+
|
|
139
|
+
```javascript
|
|
140
|
+
/** @override */
|
|
141
|
+
async init () {
|
|
142
|
+
await super.init()
|
|
143
|
+
// ...
|
|
144
|
+
}
|
|
145
|
+
```
|
|
146
|
+
|
|
147
|
+
## Type definitions
|
|
148
|
+
|
|
149
|
+
For complex types used across multiple files, it is recommended that you create a dedicated `typedefs.js` file. Use `@typedef` for object shapes and `@property` for each field.
|
|
150
|
+
|
|
151
|
+
```javascript
|
|
152
|
+
/**
|
|
153
|
+
* This file exists to define types for documentation purposes.
|
|
154
|
+
*/
|
|
155
|
+
|
|
156
|
+
/**
|
|
157
|
+
* Options for insert operations
|
|
158
|
+
* @memberof api
|
|
159
|
+
* @typedef {Object} InsertOptions
|
|
160
|
+
* @property {String} schemaName Name of the schema to validate against
|
|
161
|
+
* @property {String} collectionName DB collection to insert document into
|
|
162
|
+
* @property {Boolean} validate Whether incoming data should be validated
|
|
163
|
+
* @property {Boolean} invokePostHook Whether to invoke the post-action hook
|
|
164
|
+
*/
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
## Excluding from documentation
|
|
168
|
+
|
|
169
|
+
Use `@ignore` to exclude internal properties or methods from the generated documentation:
|
|
170
|
+
|
|
171
|
+
```javascript
|
|
172
|
+
/** @ignore */
|
|
173
|
+
this._isReady = false
|
|
174
|
+
|
|
175
|
+
/** @ignore */
|
|
176
|
+
_internalMethod () {
|
|
177
|
+
// ...
|
|
178
|
+
}
|
|
179
|
+
```
|
|
180
|
+
|
|
181
|
+
## Examples in documentation
|
|
182
|
+
|
|
183
|
+
Use `@example` to include code samples:
|
|
184
|
+
|
|
185
|
+
```javascript
|
|
186
|
+
/**
|
|
187
|
+
* Uses default configuration for API routes
|
|
188
|
+
* @example
|
|
189
|
+
* POST /
|
|
190
|
+
* GET /:_id?
|
|
191
|
+
* PUT/DELETE /:_id
|
|
192
|
+
*/
|
|
193
|
+
useDefaultRouteConfig () {
|
|
194
|
+
// ...
|
|
195
|
+
}
|
|
196
|
+
```
|
|
@@ -0,0 +1,291 @@
|
|
|
1
|
+
# API documentation guide
|
|
2
|
+
|
|
3
|
+
The Adapt authoring tool automatically generates REST API documentation using the OpenAPI 3.0 specification, rendered with Swagger UI.
|
|
4
|
+
|
|
5
|
+
This guide covers how to ensure your API routes are properly documented.
|
|
6
|
+
|
|
7
|
+
## Automatic documentation
|
|
8
|
+
|
|
9
|
+
If your module extends `AbstractApiModule` and uses `useDefaultRouteConfig()`, documentation is generated automatically for standard CRUD routes. This generates documentation for:
|
|
10
|
+
|
|
11
|
+
| Method | Route | Description |
|
|
12
|
+
| ------ | ----- | ----------- |
|
|
13
|
+
| POST | `/api/myresource` | Insert a new document |
|
|
14
|
+
| GET | `/api/myresource` | Retrieve all documents |
|
|
15
|
+
| GET | `/api/myresource/:_id` | Retrieve a single document |
|
|
16
|
+
| PUT | `/api/myresource/:_id` | Replace a document |
|
|
17
|
+
| PATCH | `/api/myresource/:_id` | Update a document |
|
|
18
|
+
| DELETE | `/api/myresource/:_id` | Delete a document |
|
|
19
|
+
| POST | `/api/myresource/query` | Query documents |
|
|
20
|
+
| GET | `/api/myresource/schema` | Retrieve the schema |
|
|
21
|
+
|
|
22
|
+
## Custom route metadata
|
|
23
|
+
|
|
24
|
+
For custom routes, provide metadata using the `meta` property on your route definition. The metadata follows the [OpenAPI 3.0 Operation Object](https://spec.openapis.org/oas/v3.0.3#operation-object) specification.
|
|
25
|
+
|
|
26
|
+
### Basic example
|
|
27
|
+
|
|
28
|
+
```javascript
|
|
29
|
+
async setValues () {
|
|
30
|
+
this.routes.push({
|
|
31
|
+
// ... route config
|
|
32
|
+
meta: {
|
|
33
|
+
post: {
|
|
34
|
+
summary: 'Publish a resource'
|
|
35
|
+
}
|
|
36
|
+
}
|
|
37
|
+
})
|
|
38
|
+
}
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
### Defining API metadata separately
|
|
42
|
+
|
|
43
|
+
For more complex APIs, define metadata in a separate file to keep your module code clean:
|
|
44
|
+
|
|
45
|
+
```javascript
|
|
46
|
+
// lib/apidefs.js
|
|
47
|
+
export default {
|
|
48
|
+
publish: {
|
|
49
|
+
post: {
|
|
50
|
+
summary: 'Publish a resource',
|
|
51
|
+
parameters: [
|
|
52
|
+
{ name: '_id', in: 'path', description: 'Resource _id', required: true }
|
|
53
|
+
],
|
|
54
|
+
responses: {
|
|
55
|
+
200: {
|
|
56
|
+
description: 'The published resource',
|
|
57
|
+
content: {
|
|
58
|
+
'application/json': {
|
|
59
|
+
schema: { $ref: '#/components/schemas/myresource' }
|
|
60
|
+
}
|
|
61
|
+
}
|
|
62
|
+
}
|
|
63
|
+
}
|
|
64
|
+
}
|
|
65
|
+
}
|
|
66
|
+
}
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
Then import and use it in your module:
|
|
70
|
+
|
|
71
|
+
```javascript
|
|
72
|
+
// lib/MyApiModule.js
|
|
73
|
+
import { AbstractApiModule } from 'adapt-authoring-api'
|
|
74
|
+
import apidefs from './apidefs.js'
|
|
75
|
+
|
|
76
|
+
class MyApiModule extends AbstractApiModule {
|
|
77
|
+
async setValues () {
|
|
78
|
+
this.routes.push({
|
|
79
|
+
// ... route config
|
|
80
|
+
meta: apidefs.publish
|
|
81
|
+
})
|
|
82
|
+
}
|
|
83
|
+
}
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
## Metadata structure
|
|
87
|
+
|
|
88
|
+
Each HTTP method on a route can have the following metadata:
|
|
89
|
+
|
|
90
|
+
| Property | Type | Description |
|
|
91
|
+
| -------- | ---- | ----------- |
|
|
92
|
+
| `summary` | String | Brief description shown in the route list |
|
|
93
|
+
| `description` | String | Detailed description shown when expanded |
|
|
94
|
+
| `parameters` | Array | Path, query, or header parameters |
|
|
95
|
+
| `requestBody` | Object | Request body schema |
|
|
96
|
+
| `responses` | Object | Response schemas keyed by status code |
|
|
97
|
+
|
|
98
|
+
### Parameters
|
|
99
|
+
|
|
100
|
+
Define parameters for path variables, query strings, or headers:
|
|
101
|
+
|
|
102
|
+
```javascript
|
|
103
|
+
parameters: [
|
|
104
|
+
{
|
|
105
|
+
name: '_id',
|
|
106
|
+
// where the parameter is set: in the path (URL), as a query parameter,
|
|
107
|
+
// or as an HTTP header
|
|
108
|
+
in: 'path',
|
|
109
|
+
description: 'The resource ID',
|
|
110
|
+
required: true
|
|
111
|
+
},
|
|
112
|
+
{
|
|
113
|
+
name: 'includeRelated',
|
|
114
|
+
in: 'query',
|
|
115
|
+
description: 'Whether to include related resources'
|
|
116
|
+
}
|
|
117
|
+
]
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
### Request body
|
|
121
|
+
|
|
122
|
+
Define the expected request body:
|
|
123
|
+
|
|
124
|
+
```javascript
|
|
125
|
+
requestBody: {
|
|
126
|
+
description: 'The resource data',
|
|
127
|
+
content: {
|
|
128
|
+
'application/json': {
|
|
129
|
+
schema: { $ref: '#/components/schemas/myresource' }
|
|
130
|
+
}
|
|
131
|
+
}
|
|
132
|
+
}
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
For inline schemas:
|
|
136
|
+
|
|
137
|
+
```javascript
|
|
138
|
+
requestBody: {
|
|
139
|
+
content: {
|
|
140
|
+
'application/json': {
|
|
141
|
+
schema: {
|
|
142
|
+
type: 'object',
|
|
143
|
+
properties: {
|
|
144
|
+
name: { type: 'string' },
|
|
145
|
+
version: { type: 'string' },
|
|
146
|
+
force: { type: 'boolean', default: false }
|
|
147
|
+
}
|
|
148
|
+
}
|
|
149
|
+
}
|
|
150
|
+
}
|
|
151
|
+
}
|
|
152
|
+
```
|
|
153
|
+
|
|
154
|
+
### Responses
|
|
155
|
+
|
|
156
|
+
Define possible responses:
|
|
157
|
+
|
|
158
|
+
```javascript
|
|
159
|
+
responses: {
|
|
160
|
+
200: {
|
|
161
|
+
description: 'Successful response',
|
|
162
|
+
content: {
|
|
163
|
+
'application/json': {
|
|
164
|
+
schema: { $ref: '#/components/schemas/myresource' }
|
|
165
|
+
}
|
|
166
|
+
}
|
|
167
|
+
},
|
|
168
|
+
404: {
|
|
169
|
+
description: 'Resource not found'
|
|
170
|
+
}
|
|
171
|
+
}
|
|
172
|
+
```
|
|
173
|
+
|
|
174
|
+
For array responses:
|
|
175
|
+
|
|
176
|
+
```javascript
|
|
177
|
+
responses: {
|
|
178
|
+
200: {
|
|
179
|
+
description: 'List of resources',
|
|
180
|
+
content: {
|
|
181
|
+
'application/json': {
|
|
182
|
+
schema: {
|
|
183
|
+
type: 'array',
|
|
184
|
+
items: { $ref: '#/components/schemas/myresource' }
|
|
185
|
+
}
|
|
186
|
+
}
|
|
187
|
+
}
|
|
188
|
+
}
|
|
189
|
+
}
|
|
190
|
+
```
|
|
191
|
+
|
|
192
|
+
## Schema references
|
|
193
|
+
|
|
194
|
+
Use `$ref` to reference schemas registered with the `jsonschema` module:
|
|
195
|
+
|
|
196
|
+
```javascript
|
|
197
|
+
{ $ref: '#/components/schemas/myresource' }
|
|
198
|
+
```
|
|
199
|
+
|
|
200
|
+
The schema name should match what you registered via `jsonschema.registerSchema()` or defined in a `.schema.json` file.
|
|
201
|
+
|
|
202
|
+
## Complete example
|
|
203
|
+
|
|
204
|
+
Here's a complete example showing custom routes with full metadata:
|
|
205
|
+
|
|
206
|
+
```javascript
|
|
207
|
+
// lib/apidefs.js
|
|
208
|
+
export default {
|
|
209
|
+
install: {
|
|
210
|
+
post: {
|
|
211
|
+
summary: 'Install a new plugin',
|
|
212
|
+
requestBody: {
|
|
213
|
+
content: {
|
|
214
|
+
'application/json': {
|
|
215
|
+
schema: {
|
|
216
|
+
type: 'object',
|
|
217
|
+
properties: {
|
|
218
|
+
name: { type: 'string' },
|
|
219
|
+
version: { type: 'string' },
|
|
220
|
+
force: { type: 'boolean', default: false }
|
|
221
|
+
}
|
|
222
|
+
}
|
|
223
|
+
}
|
|
224
|
+
}
|
|
225
|
+
},
|
|
226
|
+
responses: {
|
|
227
|
+
200: {
|
|
228
|
+
description: 'The installed plugin',
|
|
229
|
+
content: {
|
|
230
|
+
'application/json': {
|
|
231
|
+
schema: { $ref: '#/components/schemas/contentplugin' }
|
|
232
|
+
}
|
|
233
|
+
}
|
|
234
|
+
}
|
|
235
|
+
}
|
|
236
|
+
}
|
|
237
|
+
},
|
|
238
|
+
uses: {
|
|
239
|
+
get: {
|
|
240
|
+
summary: 'Get courses using this plugin',
|
|
241
|
+
parameters: [
|
|
242
|
+
{ name: '_id', in: 'path', description: 'Plugin _id', required: true }
|
|
243
|
+
],
|
|
244
|
+
responses: {
|
|
245
|
+
200: {
|
|
246
|
+
description: 'List of courses',
|
|
247
|
+
content: {
|
|
248
|
+
'application/json': {
|
|
249
|
+
schema: {
|
|
250
|
+
type: 'array',
|
|
251
|
+
items: { $ref: '#/components/schemas/course' }
|
|
252
|
+
}
|
|
253
|
+
}
|
|
254
|
+
}
|
|
255
|
+
}
|
|
256
|
+
}
|
|
257
|
+
}
|
|
258
|
+
}
|
|
259
|
+
}
|
|
260
|
+
```
|
|
261
|
+
|
|
262
|
+
```javascript
|
|
263
|
+
// lib/MyPluginModule.js
|
|
264
|
+
import { AbstractApiModule } from 'adapt-authoring-api'
|
|
265
|
+
import apidefs from './apidefs.js'
|
|
266
|
+
|
|
267
|
+
class MyPluginModule extends AbstractApiModule {
|
|
268
|
+
async setValues () {
|
|
269
|
+
this.root = 'plugins'
|
|
270
|
+
this.collectionName = 'plugins'
|
|
271
|
+
this.schemaName = 'plugin'
|
|
272
|
+
this.useDefaultRouteConfig()
|
|
273
|
+
|
|
274
|
+
this.routes.push(
|
|
275
|
+
{
|
|
276
|
+
route: '/install',
|
|
277
|
+
handlers: { post: this.installHandler.bind(this) },
|
|
278
|
+
permissions: { post: ['install:plugin'] },
|
|
279
|
+
validate: false,
|
|
280
|
+
meta: apidefs.install
|
|
281
|
+
},
|
|
282
|
+
{
|
|
283
|
+
route: '/:_id/uses',
|
|
284
|
+
handlers: { get: this.usesHandler.bind(this) },
|
|
285
|
+
permissions: { get: ['read:plugin'] },
|
|
286
|
+
meta: apidefs.uses
|
|
287
|
+
}
|
|
288
|
+
)
|
|
289
|
+
}
|
|
290
|
+
}
|
|
291
|
+
```
|
|
@@ -1,55 +1,59 @@
|
|
|
1
1
|
# Writing documentation
|
|
2
|
-
The Adapt authoring tool makes use of automatically generated documentation (powered by [JSDoc](https://jsdoc.app/)).
|
|
3
2
|
|
|
4
|
-
|
|
5
|
-
Requires annotated code (see below), but otherwise completely automated.
|
|
3
|
+
The Adapt authoring tool uses a three-tier documentation system:
|
|
6
4
|
|
|
7
|
-
**
|
|
8
|
-
|
|
5
|
+
1. **Source code reference** — Auto-generated API documentation from JSDoc comments
|
|
6
|
+
2. **Developer manual** — Handwritten markdown guides for practical usage
|
|
7
|
+
3. **REST API reference** — Auto-generated OpenAPI/Swagger documentation from route definitions
|
|
9
8
|
|
|
10
|
-
|
|
11
|
-
The source code reference is completely automated, and shouldn't need much input from you as a developer (provided your code has been correctly annotated).
|
|
9
|
+
All documentation is built using the `at-docgen` CLI provided by this module.
|
|
12
10
|
|
|
13
|
-
|
|
11
|
+
## Source code reference
|
|
14
12
|
|
|
15
|
-
|
|
16
|
-
Below are some useful tips/gotchas for any budding documentation writers.
|
|
13
|
+
JSDoc comments in your code are automatically parsed and rendered as API documentation. This requires no extra configuration beyond enabling documentation for your module, which can done by adding the following to your module's `adapt-authoring.json`:
|
|
17
14
|
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
15
|
+
```json
|
|
16
|
+
{
|
|
17
|
+
"documentation": {
|
|
18
|
+
"enable": true
|
|
19
|
+
}
|
|
20
|
+
}
|
|
21
|
+
```
|
|
23
22
|
|
|
24
|
-
|
|
23
|
+
For guidance on writing effective JSDoc comments, see the [JSDoc style guide](jsdoc-guide.md).
|
|
25
24
|
|
|
26
|
-
|
|
27
|
-
- Any required configuration options
|
|
28
|
-
- Common usage examples
|
|
29
|
-
- Any known issues/workarounds
|
|
25
|
+
## Developer manual
|
|
30
26
|
|
|
31
|
-
|
|
27
|
+
Markdown files in your module's `docs/` folder are included in the developer manual. These provide practical guides on using your module.
|
|
32
28
|
|
|
33
|
-
|
|
34
|
-
In addition to writing the manual files, you'll also need to add some configuration to the `adapt-authoring.json` file for your module to ensure that your files are included when the documentation is built.
|
|
29
|
+
To assign pages to specific sections in the manual, use the `manualPages` option:
|
|
35
30
|
|
|
36
|
-
All documentation-related options are contained in a `documentation` object at the root level:
|
|
37
31
|
```json
|
|
38
32
|
{
|
|
39
33
|
"documentation": {
|
|
40
34
|
"enable": true,
|
|
41
|
-
"
|
|
42
|
-
|
|
35
|
+
"manualPages": {
|
|
36
|
+
"getting-started.md": "basics",
|
|
37
|
+
"advanced-usage.md": "advanced"
|
|
38
|
+
}
|
|
43
39
|
}
|
|
44
40
|
}
|
|
45
41
|
```
|
|
46
42
|
|
|
47
|
-
|
|
43
|
+
Available sections include `basics`, `advanced`, `reference`, and `contributing`. You can also define custom sections if needed. Files not listed in `manualPages` are assigned to the default section.
|
|
44
|
+
|
|
45
|
+
## REST API reference
|
|
46
|
+
|
|
47
|
+
You can also add documentation for the REST API endpoints defined in your module.
|
|
48
|
+
|
|
49
|
+
If your module extends `AbstractApiModule`, REST API documentation is generated automatically from your route definitions. For custom routes or additional metadata, see the [API documentation guide](api-documentation.md).
|
|
50
|
+
|
|
51
|
+
## Custom dynamic documentation
|
|
52
|
+
|
|
53
|
+
For documentation that needs to be generated programmatically (e.g. listing all registered schemas), you can write custom documentation plugins. See [writing custom documentation plugins](custom-documentation-plugins.md) for details.
|
|
48
54
|
|
|
49
|
-
|
|
50
|
-
| --------- | ---- | :-----: | ----------- |
|
|
51
|
-
| `enable` | Boolean | `true` | Whether documentation should be generated for this module. |
|
|
52
|
-
| `manualPlugins` | Array | `[]` | A list of paths to any custom manual plugins. See [this page](custom-documentation-plugins) for more info. |
|
|
53
|
-
| `manualPages` | Object | `{}` | A key/value store mapping file names to a section (e.g. `"manual-page.md": "advanced"`). The key must be the filename only, and not a path. The section ID must match one of those defined in the config (see the [configuration reference](configuration?id=adapt-authoring-docs) for the defaults, or set your own in your config file). |
|
|
55
|
+
## Further reading
|
|
54
56
|
|
|
55
|
-
|
|
57
|
+
- [JSDoc style guide](jsdoc-guide.md) — Conventions for documenting your code
|
|
58
|
+
- [API documentation guide](api-documentation.md) — Documenting REST API endpoints
|
|
59
|
+
- [Custom documentation plugins](custom-documentation-plugins.md) — Generating dynamic documentation
|
package/docsify/styles/adapt.css
CHANGED
|
@@ -188,6 +188,7 @@ ul.toc > li {
|
|
|
188
188
|
.attribute .default pre {
|
|
189
189
|
display: inline;
|
|
190
190
|
padding: 0 5px;
|
|
191
|
+
background: transparent;
|
|
191
192
|
}
|
|
192
193
|
.markdown-section table.schema {
|
|
193
194
|
margin-top: 25px;
|
|
@@ -227,4 +228,4 @@ body.dark .markdown-section tr:nth-child(2n) {
|
|
|
227
228
|
body.dark .markdown-section blockquote {
|
|
228
229
|
background: #004a32;
|
|
229
230
|
color: inherit;
|
|
230
|
-
}
|
|
231
|
+
}
|
package/package.json
CHANGED