Skip to content

Supported frameworks

Manuscrio exports a finished static build from three documentation frameworks:

Framework Requirement
Docusaurus Any theme built on the standard theme-doc-* markup, which is Docusaurus’s published theming contract.
Starlight The Astro Starlight documentation theme.
MkDocs The Material theme. MkDocs itself prescribes no markup, so a theme supplies all of it; the built-in theme emits unrelated markup and is not supported.

The framework is detected from the built pages, so the ordinary command names no framework at all:

Terminal window
manuscrio inspect ./build

The report’s framework field names the adapter that read the build. Pass --framework docusaurus, --framework starlight, or --framework mkdocs to skip detection when you are diagnosing an unusual build. When nothing is recognised, Manuscrio says so and names the supported frameworks rather than reporting an empty site.

An MkDocs build using a theme other than Material fails that detection, because the marker it looks for is Material’s. Forcing --framework mkdocs then reports No rendered MkDocs documentation pages found rather than exporting something partial — both refusals are clean, and neither produces an incomplete manual.

One chapter opener from a real manual exported from each framework’s own documentation. The design does not change with the framework; what changes is what the framework could tell Manuscrio about itself.

A chapter opening in a manual exported from a Docusaurus build
DocusaurusPlaywright docs, Getting Started · garnet · 51 pages
A chapter opening in a manual exported from a Starlight build
StarlightAstro docs, How-to recipes · malachite · 135 pages
A chapter opening in a manual exported from a MkDocs Material build
MkDocsMaterial docs, Setup · lapis · 121 pages

The Docusaurus page carries the site’s own logo in its running header. The other two carry nothing, because logo discovery is not implemented for those adapters yet — the difference the table below records, visible in the output.

The three frameworks do not describe their documentation to the same depth, and Manuscrio reports what each one actually provides instead of inventing the rest.

Docusaurus Starlight MkDocs (Material)
Editions per locale yes yes yes
Editions per version yes no no
Editions per plugin instance yes no no
Navbar sections yes no no
--scope edition yes * yes yes
--scope section yes * no no
--scope sidebar-root yes yes yes
Logo discovered from the build yes not yet not yet

* A Docusaurus edition containing a sidebar that belongs to no navbar section is refused at both edition and section scope, and exports at --scope sidebar-root. See UNASSIGNED_DOCUMENTATION_SET.

An edition is one plugin instance, locale, and version. Docusaurus has all three concepts, so a site with two versions in three languages offers six editions.

Starlight and MkDocs have neither plugin instances nor versions, so those two thirds of the edition ID are the constants default and current. The locale still separates editions: both adapters group pages by the lang attribute of the rendered page, so a multilingual site still produces one edition per language. A single-language Starlight or MkDocs site has exactly one edition, usually default:en:current.

A documentation section is a documentation-bearing navbar entry. Only Docusaurus has that level.

For Starlight and MkDocs, --scope edition produces one manual whose top-level chapters are the sidebar roots, and --scope sidebar-root produces one manual per root. --scope section refuses, naming the scopes that work:

Edition default:en:current has no documentation sections to export: this Site Build's navigation
has no section level. Use --scope edition for one manual, or --scope sidebar-root for one per
sidebar root.

Manuscrio discovers the site’s own logo from a Docusaurus navbar and puts it on the cover and in the running header. It does not yet do this for Starlight or MkDocs: inspect reports an empty logo, and the manual carries the Manuscrio wordmark unless you pass --logo. This is a gap in those two adapters rather than a property of the frameworks, and it is the one place where a Starlight or MkDocs export needs an argument that a Docusaurus export does not.

For Docusaurus, a sidebar root is identified by the route it points at, which is stable across edits. Starlight and MkDocs sidebars do not offer an equivalent identifier, so their roots are numbered by position: set-0-1, root-2. Those IDs shift when someone inserts an entry above them.

Re-read the IDs from inspect rather than pinning them in a pipeline. See manual IDs and output file names.

For Starlight and MkDocs, every sidebar appears under unassignedDocumentationSets and assignedPages reads 0. Those fields describe attribution to a navbar section, and these frameworks have no navbar sections, so nothing is wrong and nothing is excluded — the edition exports in full. The wording is Docusaurus-shaped and will improve.