Couches et surcharge

duxt est une couche, pas un modèle. Vous l’étendez, et chaque fichier qu’elle fournit devient surchargeable : placez un fichier du même nom dans votre projet et Nuxt résout le vôtre en premier. Rien n’est copié dans votre dépôt : une mise à jour est donc un changement de version, pas une fusion.

#Ce que cela signifie en pratique

L’ordre est délibéré : les trois premiers sont des engagements de plus en plus lourds, et un composant que vous remplacez est un composant que vous maintenez désormais. Voir Surcharger le thème.

#Ce qu’elle vous retire

Une couche ne connaît jamais le projet qui repose sur elle. Deux conséquences que l’on ressent :

• @ est à vous, pas à la couche. L’alias appartient à celui qui étend duxt ; les imports de la couche utilisent donc @duxt. Le vôtre continue de pointer vers votre app/.
• Une collection se résout par rapport à la couche, pas à vous. Content enregistre comme racine de chaque collection la couche qui l’a déclarée : un cwd relatif dans la configuration de duxt pointerait donc à l’intérieur de duxt. La couche calcule pour cette raison un chemin absolu au chargement, ce qui fonctionne parce que content.config.ts est du code exécuté et non un fichier de données — et c’est sur cette jointure que repose tout le raccourci sources.

#Pourquoi c’est construit ainsi

L’alternative est un modèle de départ : nuxi init, et le thème devient une copie dans votre dépôt. Cela donne une liberté totale et aucun chemin de mise à jour — chaque amélioration du thème est un diff que quelqu’un doit appliquer à la main. Une couche inverse cela : vous héritez des améliorations et ne payez que là où vous n’étiez pas d’accord.

Ce qui fige tout cela, c’est la surface publique. Un composant, une page ou une clé d’app.config que vous pouvez surcharger est un nom dont vous dépendez : en renommer un est donc un changement cassant de la couche — ce que documente précisément la référence.