Configuration

Tout ce que le thème affiche est une donnée, et app/app.config.ts est l’endroit où un site les déclare. Il n’y a pas de second fichier de configuration : la même clé duxt porte le thème, les sources de documentation et les liens propres au site.

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

Chaque clé et sa valeur par défaut figurent dans la référence de configuration ; l’entrée sources a sa propre page.

#Comment votre configuration fusionne

Votre objet duxt est fusionné clé par clé par-dessus les valeurs par défaut de la couche, et un tableau à vous remplace celui de la couche au lieu de s’y ajouter. C’est important parce que la fusion d’app.config de Nuxt fait l’inverse : elle concatène les tableaux, ce qui vous empêcherait de retirer une seule entrée de la barre de navigation fournie par la couche. La couche ne livre donc aucune liste dans app.config et les fusionne elle-même.

La règle pratique : remplacez footer.copyright et footer.legal reste intact ; déclarez navigation et l’unique entrée de la couche disparaît.

#Deux clés sont lues à la compilation

sources et locales déterminent les collections, les routes et les liens hreflang, et les trois sont fixés avant la première requête. Modifier l’une ou l’autre impose une recompilation ; tout le reste prend effet dès que la configuration est rechargée.

#Certaines clés sont générées, non écrites

resolvedSources, layerVersion et layerRepository apparaissent dans la configuration à l’exécution et appartiennent à la compilation. resolvedSources est le manifeste que le thème lit réellement — quelle collection sert quel préfixe d’URL — résolu à partir de la liste sources que vous avez écrite. Écrire l’un des trois à la main est écrasé.

#Ce que la couche ne prétend pas savoir

links, aside.links et footer.legal sont livrés vides. Un dépôt, un gestionnaire de tickets, une communauté et des mentions légales désignent chacun un projet précis : une valeur par défaut reprenant celles de duxt tendrait à vos lecteurs un « Star on GitHub » qui étoile le travail de quelqu’un d’autre.

sections est vide pour la raison voisine : il nomme les parties de premier niveau de votre arborescence de documentation, et la couche ne peut pas savoir comment vous les avez appelées. Définissez-le une fois que votre documentation a des sections ; jusque-là, la rangée reste masquée et la barre latérale affiche tout l’arbre.

sections: [
  { label: 'Guides', to: '/guides', icon: 'lucide:book-open' },
  { label: 'Référence', to: '/reference', icon: 'lucide:list' }
]

Écrivez les vôtres — sous forme de chaîne simple, ou d’enregistrement par locale si le site sert plusieurs langues :

links: [
  {
    icon: 'simple-icons:github',
    to: 'https://github.com/vous/votre-projet',
    label: { 'en-GB': 'Repository', 'fr-FR': 'Dépôt' }
  }
]

#L’origine du site

duxt ne peut pas deviner le domaine depuis lequel il sera servi, et quatre choses en ont besoin : hreflang, canonical, le sitemap et les images Open Graph. Indiquez-le une fois, là où Nuxt le demande déjà :

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

ou via NUXT_PUBLIC_I18N_BASE_URL dans le déploiement. La couche le copie vers site.url, où les modules SEO vont le chercher. Laissé vide, chacun d’eux retombe sur une sortie relative plutôt que d’inventer un domaine — un canonical relatif se résout encore, un canonical deviné est activement faux. Voir SEO.