Versionierte Dokumentation aus den Repositories, die du schon hast
duxt ist ein Nuxt-Layer: erweitern, und dein docs/-Ordner wird zur Website, mit Theme, Suche, API-Referenz und llms.txt. Zeig damit auf andere Repositories oder auf Tags desselben, und jedes wird zu einer Version.
- Zeile Konfiguration
- 1
- Sprachen mitgeliefert
- 7
- lizenziert, quelloffen
- MIT
Live-Demo
Einrichtung
Eine Zeile, und der Ordner ist eine Website
duxt ist ein Nuxt-Layer: Erweitern bringt Theme, Seiten, Komponenten und Build-Schritte auf einmal und lässt jedes davon ersetzbar.
- Kein Generator, nichts zum Ejecten: dein Repository behält seine eigenen Dateien.
- Eine Komponente überschreiben heißt: die eigene an denselben Pfad legen.
- Baut zu einer statischen Seite, deploybar überall, wo Nuxt läuft.
export default defineNuxtConfig({
extends: ['@kirchdev/duxt']
})
export default defineAppConfig({
duxt: {
title: 'Acme',
// The folder you already write in.
sources: [{ path: 'docs' }]
}
})
Quellen
Mehrere Repositories, mehrere Versionen, eine Liste
Eine Quelle ist ein Repository und die Releases, Tags oder Branches, die daraus veröffentlicht werden. duxt macht daraus eine Collection je Version und Repository samt trennender URL-Präfixe — vollständig zur Build-Zeit.
- Klonen, Auth für private Repos und Caching kommen von Content v3 selbst und werden nicht nachgebaut.
- Eine einzelne Quelle braucht gar kein Präfix: ein Segment mit nur einem Wert unterscheidet nichts.
- Der Umschalter bleibt auf der Seite, die du liest, und sagt es, wenn es sie dort nicht gibt.
sources: [
// The repository you are standing in.
{ path: 'docs' },
// Another one: retain the newest patch in every minor line.
{
repo: 'acme/api',
path: 'docs',
releases: { select: 'minor' },
refs: [{ branch: 'main', status: 'upcoming' }]
}
]
# What the build publishes from the list beside this.
/guides/deploying # this repository, no prefix
/api/guides/retries # acme/api at the newest selected release
/api/main/guides/retries # the branch, marked "upcoming"
/api/v1.4.0/guides/retries # another retained minor line
Generierte Referenz
Referenz aus den Artefakten, die du schon auslieferst
OpenAPI-Dokumente werden zu Operations- und Schema-Seiten, Bruno-Collections zu Request-Seiten und Downloads und tfplugindocs-Bäume zu Provider-Referenzen. Alles bleibt eine gewöhnliche Content-Collection.
- OpenAPI liefert Operationen, Schemas, Beispiele und Security-Modelle.
- Bruno erhält Request-Ordner, Doku und Variablen und bietet einen bereinigten Download.
- tfplugindocs behält Provider-Kategorien und Überschriften, statt den Markdown-Baum zu glätten.
openapi: 3.1.0
info:
title: Acme API
version: 2.4.0
paths:
/widgets:
get:
operationId: listWidgets
meta {
name: List widgets
type: http
seq: 1
}
get {
url: {{baseUrl}}/widgets
body: none
auth: inherit
}
---
page_title: acme_widget Resource
subcategory: Widgets
---
# acme_widget (Resource)
Creates and manages an Acme widget.
Ausprobieren
Ein Client, der den echten Request schickt
Jede Operationsseite bringt einen Client mit. Parameter ausfüllen, den Body gegen sein Schema bearbeiten, aus dem eigenen Browser abschicken und die Antwort neben dem Beispiel lesen, das sie erzeugt hätte.
- Sieben Beispiele ab Werk, zwölf mitgeliefert, oder ein eigenes, mitgeschrieben beim Tippen.
- Der Body-Editor ist CodeMirror, bei Bedarf geladen: Eine Seite ohne Endpunkt lädt davon nichts.
- Dein Token bleibt im Browser: es gibt hier keinen Server, an den es ginge.
Anfrage senden
In deinem Stack
Derselbe Request, in deiner Sprache
Kein Beispiel für einen Request wie den obigen, sondern genau dieser. Der gewählte Server, das eingetippte Token, der bearbeitete Body: bei jedem Tastendruck neu geschrieben, in den Client, in den du ihn einfügen wirst.
- Eine Komponente: Beispiel und Button können gar nicht auseinanderlaufen.
- Eigene über `requestSamples` ergänzen oder die weglassen, die deine Leser nicht nutzen.
Beispielanfrage
curl '/demo/echo' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer demo-token' \
-d '{
"reference": "HB-1042",
"mode": "sea"
}'Maschinenleser
Auch für das Modell geschrieben, das mitliest
Derselbe Inhalt in maschinenlesbaren Formen: ein Index unter llms.txt, die Standardversionen unter llms-full.txt, jede Seite als Markdown und eine MCP-Route zum Auflisten, Suchen und Lesen.
- Textrouten können mit den Seiten vorgerendert werden; MCP liefert dieselben Collections zur Laufzeit.
- Jede Seite hat ein „als Markdown kopieren“ und einen Link, der sie in einem Assistenten öffnet.
- Die MCP-Route liefert dieselben Collections, die auch die Seite abfragt: eine Quelle, zwei Leser.
Funktionen
Erweitern statt generieren
Eine Zeile Konfiguration bringt Theme, Seiten und Komponenten. Jede Datei bleibt überschreibbar.
Quellen als Liste
Eine Deklaration pro Quelle statt einer Collection pro Version und Repository.
Versionen zum Umschalten
Alle Releases oder eines je Minor- oder Major-Linie entdecken; der Umschalter hält deine Seite.
Mehrsprachig ab Werk
Locale-Fallbacks, hreflang und richtungsbewusste UI; RTL ohne Theme-Fork ergänzen.
Vor dem Deploy geprüft
Tote Links, fehlende Anker und unübersetzte Seiten stoppen den Build oder werden darin sichtbar.
shadcn-vue
Komponenten werden kopiert, nicht importiert. Umgestalten heißt eine Datei bearbeiten.
Navigation aus dem Inhalt
Sidebar, Breadcrumbs, Inhaltsverzeichnis und Vor- oder Zurück-Links teilen einen Seitenbaum.
Maschinenlesbar
llms.txt, Seiten-Markdown und vier MCP-Werkzeuge über denselben Inhalt.