Configuración
Un archivo configura todo el sitio — qué va en él y cómo se combina.
Todo lo que muestra el tema son datos, y app/app.config.ts es donde un sitio
los declara. No hay un segundo archivo de configuración: la misma clave duxt
lleva el tema, las fuentes de documentación y los enlaces propios del sitio.
export default defineAppConfig({
duxt: {
title: 'mi proyecto',
version: 'v1.4.0',
sources: [{ path: 'docs' }]
}
});
Cada clave y su valor por defecto están en la
referencia de configuración; la entrada sources
tiene su propia página.
Cómo se combina tu configuración
Tu objeto duxt se combina clave por clave sobre los valores por defecto de la
capa, y un array tuyo reemplaza el de la capa en lugar de añadirse a él. Eso
importa porque la combinación de app.config de Nuxt hace lo contrario:
concatena arrays, lo que te dejaría sin poder eliminar una sola entrada de la
barra de navegación que trae la capa. Por eso la capa no incluye ninguna lista
en app.config y las combina ella misma.
La regla práctica: sobrescribe footer.copyright y footer.legal queda
intacto; declara navigation y la única entrada de la capa desaparece.
Dos claves se leen en tiempo de compilación
sources y locales deciden las colecciones, las rutas y los enlaces
hreflang, y las tres quedan fijadas antes de la primera petición. Cambiar
cualquiera de ellas exige recompilar; todo lo demás surte efecto en cuanto se
recarga la configuración.
Algunas claves se generan, no se escriben
resolvedSources, layerVersion y layerRepository aparecen en la
configuración en tiempo de ejecución y pertenecen a la compilación.
resolvedSources es el manifiesto que el tema lee realmente — qué colección
sirve qué prefijo de URL — resuelto a partir de la lista sources que
escribiste. Escribir cualquiera de los tres a mano se sobrescribe.
Lo que la capa no presume saber
links, aside.links y footer.legal se entregan vacíos. Un repositorio,
un gestor de incidencias, una comunidad y un aviso legal nombran cada uno a un
proyecto concreto, así que un valor por defecto con los de duxt pondría ante tus
lectores un «Star on GitHub» que marca el trabajo de otra persona.
sections se entrega vacío por la razón vecina: nombra las partes de primer
nivel de tu árbol de documentación, y la capa no puede saber cómo las llamaste.
Defínelo cuando tu documentación tenga secciones; hasta entonces la fila
permanece oculta y la barra lateral muestra el árbol completo.
sections: [
{ label: 'Guías', to: '/guides', icon: 'lucide:book-open' },
{ label: 'Referencia', to: '/reference', icon: 'lucide:list' }
]
Escribe los tuyos — como cadena simple, o como registro por locale si el sitio sirve varios idiomas:
links: [
{
icon: 'simple-icons:github',
to: 'https://github.com/tu/tu-proyecto',
label: { 'en-GB': 'Repository', 'es-ES': 'Repositorio' }
}
]
Las claves i18n de la capa traducen los valores por defecto que ella entrega. Son internas: renombrar una no es un cambio incompatible, e i18n responde a una clave inexistente imprimiendo la clave — así que la rotura sería silenciosa en tu sitio. Usa un literal, una clave propia o la forma de registro de arriba.
El origen del sitio
duxt no puede adivinar el dominio desde el que se servirá, y cuatro cosas lo
necesitan: hreflang, canonical, el sitemap y las imágenes de Open Graph.
Decláralo una vez, donde Nuxt ya lo pide:
i18n: { baseUrl: 'https://docs.example.com' }
o como NUXT_PUBLIC_I18N_BASE_URL en el despliegue. La capa lo copia a
site.url, que es donde miran los módulos de SEO. Si no se define, cada uno de
ellos degrada a salida relativa en lugar de inventar un dominio — un canonical
relativo sigue resolviéndose, uno adivinado es activamente erróneo. Véase
SEO.