|
| 1 | +--- |
| 2 | +title: Developer Documentation |
| 3 | +--- |
| 4 | + |
| 5 | +# Documentation for Developers |
| 6 | + |
| 7 | +As part of good practice, you should write documentation to assist future developers that might want to |
| 8 | +add to or modify the functionalities of your bundle. |
| 9 | + |
| 10 | +## Locations |
| 11 | + |
| 12 | +Developer documentation for bundles are located in two places: |
| 13 | + |
| 14 | +### 1. As a `README` file at the root of your bundle: |
| 15 | + |
| 16 | +```dirtree |
| 17 | +name: bundle0 |
| 18 | +children: |
| 19 | +- name: manifest.json |
| 20 | + comment: the |
| 21 | +- name: package.json |
| 22 | + comment: usual stuff |
| 23 | +- src |
| 24 | +- name: README.md |
| 25 | + comment: Your README file here! |
| 26 | +``` |
| 27 | + |
| 28 | +This file should contain basic information regarding your bundle such that someone wouldn't have to |
| 29 | +install any further dependencies to be able to view it (i.e they wouldn't need to spin up |
| 30 | +the entire documentation server to read it). |
| 31 | + |
| 32 | +If you have more complex documentation needs, you can follow the instructions in the next section. |
| 33 | + |
| 34 | +### 2. As a collection of Markdown files located [here](../../../lib/dev): |
| 35 | + |
| 36 | +Within the `dev` folder, markdown files are collated and displayed in the index page. Each |
| 37 | +markdown file/folder structure represents a separate bundle. |
| 38 | + |
| 39 | +For example: |
| 40 | +```dirtree |
| 41 | +name: dev |
| 42 | +children: |
| 43 | +- name: index.md |
| 44 | + comment: Index Page |
| 45 | +
|
| 46 | +- name: curve.md |
| 47 | + comment: Documentation for the curve bundle |
| 48 | +
|
| 49 | +- name: game.md |
| 50 | + comment: Documentation for the game bundle |
| 51 | +
|
| 52 | +- name: your_bundle.md |
| 53 | + comment: Add your own bundle's documentation! |
| 54 | +``` |
| 55 | + |
| 56 | +### 3. Throughout Your Code |
| 57 | + |
| 58 | +Especially when your bundle intentionally breaks conventions or rules, or when you need to do |
| 59 | +something unconventional, you should leave comments in your source code detailing why. |
| 60 | + |
| 61 | +For example, the `communication` bundle uses the `mqtt` bundle but doesn't use its main |
| 62 | +export. The comment explains why the alternate import is being used. |
| 63 | +```ts |
| 64 | +import { connect, type MqttClient, type QoS } from 'mqtt/dist/mqtt'; |
| 65 | +// Need to use "mqtt/dist/mqtt" as "mqtt" requires global, which SA's compiler does not define. |
| 66 | +``` |
| 67 | + |
| 68 | +## What to include? |
| 69 | + |
| 70 | +You should document: |
| 71 | +- Your thought processes behind your code |
| 72 | +- How you intend for cadets to use your bundle |
| 73 | +- Information flows (like what functions write to the module context etc...) |
| 74 | +- Any interesting quirks or configurations required to get your bundle working |
| 75 | +- How the underlying implementation of your bundle actually works |
| 76 | + |
| 77 | +::: details The `pix_n_flix` bundle |
| 78 | +A good example for the last point is the `pix_n_flix` bundle, where many of the cadet facing functions, when called, |
| 79 | +actually queue their effects to be applied and don't execute immediately. |
| 80 | + |
| 81 | +Documenting how and when those functions actually |
| 82 | +execute and interact with cadet code would be helpful to future developers working with the bundle. |
| 83 | +::: |
| 84 | + |
| 85 | +> [!IMPORTANT] Global Variables |
| 86 | +> Though the use of global variables is generally considered bad practice, they might not be avoidable |
| 87 | +> in the design of your bundle. (In fact, many of the older bundles need to rely on global variables) |
| 88 | +> |
| 89 | +> You _should_ document where such variables are written to and read from. |
0 commit comments