Mit Workspaces können Sie mehrere Dokumentationsprojekte aus einem einzigen Repository erstellen und bereitstellen. Jedes Projekt behält seine eigene Konfiguration. Globale Einstellungen, die am Workspace-Root definiert sind, vererben sich automatisch an jedes Projekt.
docs.example.com/ → Hauptdokumentation
docs.example.com/sdk/ → SDK-Referenz
docs.example.com/cli/ → CLI-Dokumentation
Einrichtung
1. Verzeichnisstruktur
Ein Verzeichnis pro Projekt. Gemeinsame Assets und die globale Konfiguration befinden sich im Repository-Root.
my-docs/
├── assets/ ← Gemeinsame Assets (werden von allen Projekten geerbt)
├── main-docs/
│ ├── docmd.config.json ← Projektkonfiguration (überschreibt Root-Standards)
│ └── docs/ ← Projektinhalte
├── sdk-docs/
│ ├── docmd.config.json
│ └── docs/
├── docmd.config.json ← Workspace-Root-Konfiguration
└── package.json
2. Root-Workspace-Konfiguration
Die Root-Datei docmd.config.json verwendet den Schlüssel workspace. Alle übergeordneten Schlüssel (z. B. theme, menubar, logo) dienen als globale Standardwerte für jedes Projekt.
{
"workspace": {
"projects": [
{ "prefix": "/", "src": "main-docs", "title": "Doku" },
{ "prefix": "/sdk", "src": "sdk-docs", "title": "SDK-Referenz" }
],
"switcher": {
"enabled": true,
"position": "sidebar-top"
}
},
"theme": { "name": "default", "appearance": "system" },
"logo": {
"light": "assets/logo-dark.svg",
"dark": "assets/logo-light.svg"
},
"menubar": [
{ "text": "GitHub", "url": "https://github.com/my-org/my-repo", "external": true }
]
}
workspace-Optionen
| Schlüssel | Typ | Beschreibung |
|---|---|---|
projects |
Array |
Liste der Projekteinträge. Mindestens ein Eintrag muss prefix: "/" verwenden. |
switcher |
Object |
Steuert die Sichtbarkeit und Position des Projekt-Switchers. |
Projekteintragsfelder
| Schlüssel | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
prefix |
String |
✅ | URL-Präfix. Verwenden Sie "/" für das Root-Projekt. |
src |
String |
✅ | Verzeichnispfad (relativ zum CWD), der die Inhalte des Projekts und eine optionale docmd.config.json enthält. |
title |
String |
- | Anzeigename, der in der UI des Projekt-Switchers angezeigt wird. |
3. Konfiguration auf Projektebene
Jedes Projektverzeichnis kann eine eigene docmd.config.json besitzen. Hier definierte Einstellungen überschreiben die Standards des Workspace-Roots.
{
"title": "SDK-Referenz",
"src": "docs",
"plugins": {
"search": {},
"openapi": {}
}
}
Wenn keine lokale Konfigurationsdatei gefunden wird, wendet die Engine ein Zero-Config-Auto-Routing unter Verwendung der Workspace-Standards an.
4. Globale Konfigurationsvererbung
Jeder im Root-Workspace definierte Schlüssel gilt automatisch für jedes Projekt. Projektkonfigurationen können selektiv alle diese globalen Werte überschreiben.
| Ebene | Priorität |
|---|---|
| Root-Workspace-Konfiguration | Niedrigste (wird zuerst als Standard angewendet) |
Projekt-docmd.config.json |
Höher (überschreibt Root-Standards) |
Projekt-navigation.json |
Höchste (gewinnt immer für die Navigation) |
Beispiel: Definieren Sie Ihr globales theme und menubar einmal im Root. Jedes Projekt muss nur title, src and seine eigenen plugins festlegen.
Eine navigation.json-Datei auf Projektebene hat immer Vorrang vor jedem navigation-Array, das in der Root-Konfiguration des Workspace definiert ist. Wenn keine von beiden existiert, fällt docmd auf die automatische Verzeichnis-Scannung zurück.
Projekt-Switcher
Der Projekt-Switcher rendert eine schlanke UI-Komponente zum Navigieren zwischen Workspace-Projekten.
Konfiguration
{
"workspace": {
"switcher": {
"enabled": true,
"position": "sidebar-top"
}
}
}
| Position | Beschreibung |
|---|---|
sidebar-top (Standard) |
Oben in der Seitenleiste angeheftet, über der Navigation. |
sidebar-bottom |
Unten in der Seitenleiste angeheftet. |
options-menu |
Integriert in das Header-Optionsmenü neben Suche und Theme-Umschaltern. |
Der Switcher wird nur gerendert, wenn zwei oder mehr Projekte definiert sind.
Assets
Gemeinsame Assets
Platzieren Sie Logos, Favicons und globales CSS im Root-Verzeichnis assets/. Die Engine kopiert diese bei dev und build automatisch in die Ausgabe jedes Projekts.
Projektspezifische Assets
Jedes Projekt kann ein eigenes assets/-Verzeichnis besitzen. Projekt-Assets haben bei Namenskonflikten Vorrang vor gemeinsamen Assets.
Bauen & Entwicklung
Dev-Server
npx @docmd/core dev
Baut alle Projekte und stellt sie über einen einzigen Port bereit. Dateiänderungen lösen zielgerichtete, projektspezisifische Rebuilds aus - nur das modifizierte Projekt wird neu gerendert, nicht der gesamte Workspace. Änderungen an der Root-Konfiguration lösen einen vollständigen Workspace-Rebuild aus.
Produktions-Build
npx @docmd/core build
Gibt ein einzelnes statisches Verzeichnis aus. Alle Projekte werden in ihre jeweiligen Unterpfade zusammengeführt. Es ist kein Reverse-Proxy oder eine komplexe CI-Pipeline erforderlich.
Regeln & Einschränkungen
- Root-Projekt erforderlich: Genau ein Projekt muss
prefix: "/"verwenden. - Eindeutige Präfixe: Jedes Projekt muss ein eindeutiges URL-Präfix verwenden.
outnur im Root: Nur die Root-Workspace-Konfiguration steuert das Ausgabeverzeichnis. Konfigurationen von Child-Projekten dürfenoutnicht definieren.- Keine Präfixkonflikte: Wenn ein Root-Projekt einen Ordner namens
sdk/hat und ein anderes Projektprefix: "/sdk"verwendet, gibt die Engine eine Konfliktwarnung aus. Das präfigierte Projekt gewinnt immer.
Migration von Legacy-Konfigurationen
Die Syntax des projects-Arrays vor 0.8.3 und andere ältere Konfigurationsschlüssel werden zur Abwärtskompatibilität automatisch in das moderne workspace-Schema überführt.
Obwohl manuelle Updates nicht zwingend erforderlich sind, können Sie Ihre Konfigurationsdatei mithilfe der CLI automatisch auf das moderne Schema aktualisieren.
Führen Sie npx @docmd/core migrate --upgrade aus, um Ihre Root-Konfiguration automatisch auf das aktuelle Schema umzuschreiben.