docs: API Reference

[AlexStormwood]

Make sure everything that is "user-facing" has JSDoc comments, and implement a CICD pipeline to compile that into a deployed website.

API Sections

Confirm that the sections are in-use in the project, and document them.

• Guides
  • Quick Start
  • The Basics
    • 00 - Understanding This Package
    • 01 - The SuperCamo Singleton
    • 02 - Document Basics
    • 03 - Embedded Document Basics
    • 04 - DB Client Basics
  • Package Exports
• Reference
  • Classes:
    • CollectionAccessor
    • CollectionListEntry
    • NedbClient
    • SuperCamo
    • NedbBaseDocument
      • Make sure to note that TypeScript intellisense shows more data (eg. rules) on a CTRL+Space shortcut in VSCode
    • NedbDocument
    • NedbEmbeddedDocument
  • Interfaces:
    • BaseDocument
    • CollectionAccessor
    • CollectionsListEntry
    • DocumentBaseData
    • DocumentConstructorData
    • DocumentKeyRule
    • DocumentObjectData
    • findManyDocumentsOptions
    • findManyObjectsOptions
    • findOneObjectOptions
    • NedbClientEntry
    • updateManyOptions
    • updateOptions
  • Logging:
    • SuperCamoLogger
  • Error Classes - might just leave these as-is for now, they only really exist for catch specificity anyway

Automation

GitHub Actions workflow requirements.

• Repo configured with GitHub Pages deployment.
• Repo configured with a JSDoc build command.
• Workflow configured to run the above JSDoc build command.
• Workflow configured to upload JSDoc build output to gh-pages branch.

[AlexStormwood]

Some sections (mostly in Interfaces) don't show their explanation content in the generated website, but that's fine - it's nothing that package users are meant to be using anyway. And if they do need to dig into it, then the JSDoc comments/intellisense in their coding editor will work to provide info as a workaround instead.