Skip to content

Host API documentation for WebARKit libraries (jsfeatNext first) on webarkit.org #49

Description

@kalwalt

Summary

Decide and set up a hosting strategy for API documentation of the WebARKit org's repositories, integrated with www.webarkit.org — starting with jsfeatNext, whose full API docs are now generatable.

Context

  • jsfeatNext now has complete TSDoc coverage across its API and a TypeDoc setup: npm run docs generates a full static HTML site (86 pages) into docs/api/ (see refactor: de-duplicate the stub/monolith structure — one real module per class (#47) jsfeatNext#71).
  • The generated output is deliberately gitignored and not published anywhere yet.
  • Publishing via the repo's own GitHub Pages was ruled out: the org's web presence is www.webarkit.org (served from this repository), so docs should live under/next to it rather than on scattered per-repo pages.
  • Other WebARKit repos (webarkit core, jsartoolkitNFT, etc.) will want the same treatment, so this should be a single org-wide pattern, not a per-repo improvisation.

Options to evaluate

  1. Subpaths on this site — e.g. webarkit.org/docs/jsfeat-next/, webarkit.org/docs/<repo>/: each library repo has a CI job that builds its docs and pushes them into this repository (or uploads an artifact this repo's build consumes).
  2. Docs subdomain — e.g. docs.webarkit.org, a dedicated docs site (could still be GitHub Pages under the hood, on a separate repo/branch) aggregating all libraries.
  3. Per-repo gh-pages + central index — each repo publishes its own docs on gh-pages; www.webarkit.org just links to them (least integration, least central control).

Considerations

  • Versioning: publish docs per release tag (e.g. /docs/jsfeat-next/0.7.6/ + latest) or only latest?
  • Automation: jsfeatNext is about to get a tag-triggered release workflow (Automate the release process and npm publishing jsfeatNext#61) — a docs-publish step would slot naturally into it.
  • Consistency: TypeDoc for the TypeScript repos; other tooling may be needed for the C/C++/emscripten repos.

Acceptance criteria

  • A documented decision on where org API docs live and how repos publish to it
  • jsfeatNext docs published there as the pilot

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions