Zum Inhalt springen
duxt

Konfiguration

Eine Datei konfiguriert die ganze Seite — was hineingehört, und wie sie zusammengeführt wird.

Alles, was das Theme zeigt, sind Daten, und app/app.config.ts ist der Ort, an dem eine Seite sie angibt. Es gibt keine zweite Konfigurationsdatei: derselbe duxt-Schlüssel trägt das Theme, die Dokumentationsquellen und die eigenen Links der Seite.

export default defineAppConfig({
  duxt: {
    title: 'mein Projekt',
    version: 'v1.4.0',
    sources: [{ path: 'docs' }]
  }
});

Jeder Schlüssel und sein Standardwert stehen in der Konfigurationsreferenz; der Eintrag sources hat eine eigene Seite.

Wie deine Konfiguration zusammengeführt wird

Dein duxt-Objekt wird schlüsselweise über die Standardwerte der Ebene gelegt, und ein Array von dir ersetzt das der Ebene, statt daran angehängt zu werden. Das ist wichtig, weil Nuxts eigene app.config-Zusammenführung das Gegenteil tut: Sie verkettet Arrays, womit du einen einzelnen Navbar-Eintrag der Ebene nicht mehr entfernen könntest. Deshalb liefert die Ebene in app.config überhaupt keine Listen aus und führt sie selbst zusammen.

Die praktische Regel: Überschreibe footer.copyright, und footer.legal bleibt unangetastet; deklariere navigation, und der eine Eintrag der Ebene ist weg.

Zwei Schlüssel werden zur Build-Zeit gelesen

sources und locales entscheiden über die Collections, die Routen und die hreflang-Links, und alle drei stehen vor der ersten Anfrage fest. Eines von beiden zu ändern erfordert einen erneuten Build; alles andere wirkt, sobald die Konfiguration neu geladen ist.

Manche Schlüssel werden erzeugt, nicht geschrieben

resolvedSources, layerVersion und layerRepository erscheinen zur Laufzeit in der Konfiguration und gehören dem Build. resolvedSources ist das Manifest, das das Theme tatsächlich liest — welche Collection welches URL-Präfix bedient — aufgelöst aus der sources-Liste, die du geschrieben hast. Schreibst du eines der drei von Hand, wird es überschrieben.

Was die Ebene nicht zu wissen vorgibt

links, aside.links und footer.legal werden leer ausgeliefert. Ein Repository, ein Issue-Tracker, eine Community und ein Impressum benennen jeweils ein bestimmtes Projekt — ein Standardwert mit duxts eigenen Angaben würde deinen Lesern ein „Star on GitHub“ hinstellen, das fremde Arbeit mit einem Stern versieht.

sections ist aus dem benachbarten Grund leer: Es benennt die obersten Teile deines Dokumentationsbaums, und die Ebene kann nicht wissen, wie du sie genannt hast. Setze es, sobald deine Doku Sektionen hat; bis dahin bleibt die Zeile verborgen und die Seitenleiste zeigt den ganzen Baum.

sections: [
  { label: 'Anleitungen', to: '/guides', icon: 'lucide:book-open' },
  { label: 'Referenz', to: '/reference', icon: 'lucide:list' }
]

Schreibe deine eigenen — als einfache Zeichenkette oder als Datensatz je Locale, wenn die Seite mehrere Sprachen bedient:

links: [
  {
    icon: 'simple-icons:github',
    to: 'https://github.com/du/dein-projekt',
    label: { 'en-GB': 'Repository', 'de-DE': 'Repository' }
  }
]

Der Ursprung der Seite

duxt kann die Domain nicht erraten, unter der es ausgeliefert wird, und vier Dinge brauchen sie: hreflang, canonical, die Sitemap und die Open-Graph-Bilder. Gib sie einmal an, dort, wo Nuxt ohnehin danach fragt:

i18n: { baseUrl: 'https://docs.example.com' }

oder als NUXT_PUBLIC_I18N_BASE_URL im Deployment. Die Ebene kopiert sie nach site.url, wo die SEO-Module nachsehen. Bleibt sie ungesetzt, fällt jedes von ihnen auf relative Ausgabe zurück, statt eine Domain zu erfinden — ein relatives canonical löst immer noch auf, ein geratenes ist aktiv falsch. Siehe SEO.

War diese Seite hilfreich?