Guides
Task-oriented guides for configuring docvia, integrating it with a framework, and extending the pipeline.
On this page
The guides cover docvia from the user's side: how to configure it, wire it into an app, and extend it. For the API surface of an individual package, see the Packages reference.
In this section
- Configuration lists every option accepted by
defineConfig, with defaults and types. - Framework integration covers SvelteKit, Next.js, React with Vite, and TanStack Start.
- CLI reference documents every
docviacommand and flag. - Writing plugins explains the five pipeline hook points and how to author a plugin.
- Architecture describes the compile pipeline, the
IR, and what
defineDocs()compiles to. - Incremental builds covers how content hashing decides what to recompile.
The mental model
docvia has two halves:
flowchart LR
subgraph core ["1. Compile core"]
MD["Markdown"] --> CS["PagePipeline"] --> MG["Lazy page modules"]
end
subgraph app ["2. Framework integration"]
MG --> SRC["getPage · getPages · pageTree"] --> REN["Renderer"] --> PAGE["Framework-native page"]
end - The compile core (
PagePipeline) reads Markdown, runs it through the pipeline, and produces a compiled module per page, at build time, in the dev server, or per request. - A framework integration consumes those modules. A
defineDocs()collection wrapped inloader()gives yougetPage,getPages, andpageTree, and a renderer turns each page's content into framework-native output.
The same core runs in three modes, build, dev, and SSR, so their output is identical. Plugins, the frontmatter schema, content hashing, and syntax highlighting are all details of how the core produces those modules. See Architecture for the full picture.