Skip to content

site-architecture.adoc

Latest commit

 

History

History
31 lines (22 loc) · 1.43 KB

site-architecture.adoc

File metadata and controls

31 lines (22 loc) · 1.43 KB
Raw

Site architecture: SolidStart + Antora

Table of Contents

Does a “Solid extension that loads Antora” make sense?

Not really. Antora is a build-time docs site generator (AsciiDoc → static HTML + UI bundle + extensions). SolidStart is an app framework. They do not share a runtime component model.

What does make sense is concurrent use:

  • SolidStart owns marketing, news, theme, docs onboarding (/docs), and navigation chrome.

  • Antora owns versioned docs UX (nav, page layout, xrefs, UI bundle) at /manual/.

  • CI builds Antora into site/public/manual/ so GitHub Pages serves both from one deploy.

  • AsciiDoc sources stay in-repo (docs/) as the single authoring source.

/                 ← SolidStart (home, news, about)
/docs             ← SolidStart onboarding gate → CTA into Antora
/manual/**        ← Antora static output (copied into public/manual)

Live updates

Antora output is static. “Live on source update” means rebuild (push → Actions → Pages), not hot-reloading Antora inside Solid at runtime. If you later need true live preview, add a separate authoring preview (AsciiDoc → HTML) — that is not Antora-in-Solid.

Advisable?

Yes: side-by-side static composition is the usual, low-friction pattern (framework site + Antora under a sibling path). Building a Solid “Antora loader” would reimplement Antora’s site assembler poorly and fight Antora’s extension ecosystem.