|
| 1 | +# SuperSTAC documentation |
| 2 | + |
| 3 | +A Fumadocs / Next.js site for **https://spatialnode.com/superstac**, with the approved logo, a custom landing page, search, light/dark themes, and Python/Rust/CLI guides. Source content lives in `content/docs`; branding originals stay in `assets` for the repository READMEs. |
| 4 | + |
| 5 | +## Develop |
| 6 | + |
| 7 | +Use Node **22.19+** (the latest Node 22 LTS patch is recommended). |
| 8 | + |
| 9 | +```bash |
| 10 | +cd docs |
| 11 | +nvm use |
| 12 | +npm install --global pnpm@9.8.0 |
| 13 | +pnpm install --frozen-lockfile |
| 14 | +pnpm dev |
| 15 | +``` |
| 16 | + |
| 17 | +Open **http://localhost:3000/superstac**. The reference pages start at `/superstac/docs`. The `/superstac` base path is intentionally enabled in development so broken asset and search URLs can be caught before deployment. |
| 18 | + |
| 19 | +```bash |
| 20 | +pnpm check |
| 21 | +pnpm build |
| 22 | +pnpm start |
| 23 | +# In another terminal, while the production server is running: |
| 24 | +pnpm test:links |
| 25 | +``` |
| 26 | + |
| 27 | +`test:links` visits all authored docs routes, checks rendered internal links and assets, and exercises the search endpoint. Set `DOCS_TEST_ORIGIN` if the server is on another port. |
| 28 | + |
| 29 | +## Authoring |
| 30 | + |
| 31 | +- Add Markdown or MDX pages in `content/docs`. |
| 32 | +- Set `title` and `description` in frontmatter and order pages in each folder's `meta.json`. |
| 33 | +- Link between docs using `/docs/...`. Next.js adds `/superstac` for these links. |
| 34 | +- Public asset/download URLs use `/superstac/...` explicitly; plain image URLs do not receive Next.js base-path handling. |
| 35 | +- Edit the complete downloadable YAML in `public/examples/superstac.yml` and keep the quickstart snippet in sync. |
| 36 | +- Build hooks copy the two approved SVGs from `assets` to `public/brand`. Do not edit generated copies. |
| 37 | +- The Spatialnode footer badge is in `public/powered-by-spatialnode.svg`; its dark variant preserves the paths with white lettering and a dark background. Both follow the site's theme toggle. |
| 38 | +- The runnable Python notebook lives in `public/notebooks/superstac-python-quickstart.ipynb`, served at `/superstac/notebooks/superstac-python-quickstart.ipynb`. Keep this single source of truth free of saved outputs, execution counts, credentials, and personal runtime metadata. Its documentation page is `content/docs/python/notebook.mdx`. |
| 39 | +- Verify examples against the source when the alpha API changes. The docs record current implementation behavior, including limitations; they do not promise future features. |
| 40 | + |
| 41 | +Commit `pnpm-lock.yaml` whenever dependencies change. The Docker build uses pnpm 9.8.0 with `--frozen-lockfile`; dependency drift fails the build. |
| 42 | + |
| 43 | +## Python notebook |
| 44 | + |
| 45 | +Download [the notebook](public/notebooks/superstac-python-quickstart.ipynb) and upload it to Colab, or open it locally with Jupyter. Its cells install the Python dependencies when the reader runs them, search two public catalogs, show a footprint map, and export a ZIP of the results. They have not been executed against live catalogs here. |
| 46 | + |
| 47 | +The direct **Open in Colab** links target this file on GitHub's `main` branch and become usable after it is pushed there. Before publishing an updated notebook, run all cells in a fresh runtime, check the diagnostics and downloaded results, then clear outputs and execution counts before saving it back to the repository. |
| 48 | + |
| 49 | +## GitHub deployment automation |
| 50 | + |
| 51 | +[Deploy docs](../.github/workflows/docs-deploy.yml) runs on **published GitHub releases**, including prereleases, and through **Actions → Deploy docs → Run workflow**. Ordinary pushes and tag creation alone do not deploy. Publish a release only when its corresponding package is available; the workflow does not publish packages or wait for a separate package-publishing workflow. |
| 52 | + |
| 53 | +The workflow checks out the release tag or the manually supplied Git ref. It builds an AMD64 image, runs the Dockerfile's type check and production build, starts the resulting container, and checks pages, links, assets, search, and the 404 response. Only then does it publish to GHCR and deploy through the Coolify API. Use an x86-64 Coolify server for this workflow; an ARM server needs a matching runner/image platform. |
0 commit comments