Camadas e substituição

O duxt é uma camada, não um modelo. Estende-la e cada ficheiro que ela traz passa a ser substituível: coloca um ficheiro com o mesmo nome no teu projeto e o Nuxt resolve o teu primeiro. Nada é copiado para o teu repositório, por isso uma atualização é um salto de versão e não uma fusão.

#O que isso significa na prática

A ordem é deliberada: os três primeiros são compromissos progressivamente maiores, e um componente que substituis é um componente que passas a manter. Ver Substituir o tema.

#O que te tira

Uma camada nunca conhece o projeto que assenta sobre ela. Duas consequências que se sentem:

• @ é teu, não da camada. O alias pertence a quem estende o duxt, por isso as importações da própria camada usam @duxt. O teu continua a apontar para o teu app/.
• Uma coleção resolve contra a camada, não contra ti. O Content regista como raiz de cada coleção a camada que a declarou, pelo que um cwd relativo na configuração do próprio duxt apontaria para dentro do duxt. A camada calcula por isso um caminho absoluto no carregamento, o que funciona porque content.config.ts é código executado e não um ficheiro de dados — e é sobre essa junção que assenta todo o atalho sources.

#Porque é feito assim

A alternativa é um modelo inicial: nuxi init, e o tema passa a ser uma cópia dentro do teu repositório. Isso dá liberdade total e nenhum caminho de atualização — cada melhoria no tema é um diff que alguém tem de aplicar à mão. Uma camada inverte isso: herdas as melhorias e só pagas onde discordaste.

O que fixa tudo isto é a superfície pública. Um componente, uma página ou uma chave de app.config que podes substituir é um nome do qual dependes, por isso renomear um é uma alteração incompatível da camada — que é precisamente o que a referência documenta.