Configuração

Tudo o que o tema mostra são dados, e app/app.config.ts é onde um site os declara. Não há um segundo ficheiro de configuração: a mesma chave duxt transporta o tema, as fontes de documentação e os links do próprio site.

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

Cada chave e o seu valor por omissão estão na referência de configuração; a entrada sources tem uma página própria.

#Como a tua configuração é combinada

O teu objeto duxt é combinado chave a chave sobre os valores por omissão da camada, e um array teu substitui o da camada em vez de lhe ser acrescentado. Isso importa porque a combinação de app.config do Nuxt faz o contrário: concatena arrays, o que te deixaria sem poder remover uma única entrada da barra de navegação que a camada traz. Por isso a camada não entrega listas nenhumas em app.config e combina-as ela própria.

A regra prática: substitui footer.copyright e footer.legal fica intacto; declara navigation e a única entrada da camada desaparece.

#Duas chaves são lidas em tempo de compilação

sources e locales decidem as coleções, as rotas e os links hreflang, e as três ficam definidas antes do primeiro pedido. Alterar qualquer uma delas exige nova compilação; tudo o resto tem efeito assim que a configuração é recarregada.

#Algumas chaves são geradas, não escritas

resolvedSources, layerVersion e layerRepository aparecem na configuração em tempo de execução e pertencem à compilação. resolvedSources é o manifesto que o tema realmente lê — que coleção serve que prefixo de URL — resolvido a partir da lista sources que escreveste. Escrever qualquer um dos três à mão é sobrescrito.

#O que a camada não presume saber

links, aside.links e footer.legal são entregues vazios. Um repositório, um gestor de issues, uma comunidade e um aviso legal nomeiam cada um um projeto concreto, pelo que um valor por omissão com os do duxt entregaria aos teus leitores um «Star on GitHub» que marca o trabalho de outra pessoa.

sections é entregue vazio pela razão vizinha: nomeia as partes de topo da tua árvore de documentação, e a camada não pode saber como lhes chamaste. Define-o quando a tua documentação tiver secções; até lá a linha fica escondida e a barra lateral mostra a árvore inteira.

sections: [
  { label: 'Guias', to: '/guides', icon: 'lucide:book-open' },
  { label: 'Referência', to: '/reference', icon: 'lucide:list' }
]

Escreve os teus — como texto simples, ou como registo por locale se o site servir vários idiomas:

links: [
  {
    icon: 'simple-icons:github',
    to: 'https://github.com/tu/o-teu-projeto',
    label: { 'en-GB': 'Repository', 'pt-PT': 'Repositório' }
  }
]

#A origem do site

O duxt não consegue adivinhar o domínio a partir do qual será servido, e quatro coisas precisam dele: hreflang, canonical, o sitemap e as imagens Open Graph. Indica-o uma vez, onde o Nuxt já o pergunta:

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

ou como NUXT_PUBLIC_I18N_BASE_URL no deployment. A camada copia-o para site.url, que é onde os módulos de SEO procuram. Se ficar por definir, cada um deles recai em saída relativa em vez de inventar um domínio — um canonical relativo ainda resolve, um adivinhado está ativamente errado. Ver SEO.