Ebenen und Überschreiben

duxt ist eine Ebene, keine Vorlage. Du erweiterst sie, und jede Datei, die sie mitbringt, wird überschreibbar: Lege eine Datei gleichen Namens in dein eigenes Projekt, und Nuxt löst deine zuerst auf. Nichts wird in dein Repository kopiert, ein Upgrade ist also ein Versionssprung statt einer Zusammenführung.

#Was das in der Praxis heißt

Die Reihenfolge ist Absicht: Die ersten drei sind zunehmend größere Bindungen, und eine Komponente, die du ersetzt, ist eine Komponente, die du nun pflegst. Siehe Theme überschreiben.

#Was sie dir nimmt

Eine Ebene kennt nie das Projekt, das auf ihr steht. Zwei Folgen, die ein Konsument spürt:

• @ gehört dir, nicht der Ebene. Der Alias gehört dem, der duxt erweitert, deshalb nutzen die Importe der Ebene @duxt. Deiner zeigt weiterhin auf dein app/.
• Eine Collection löst gegen die Ebene auf, nicht gegen dich. Content merkt sich für jede Collection als Wurzel die Ebene, die sie deklariert hat — ein relatives cwd in duxts eigener Konfiguration zeigte also in duxt hinein. Die Ebene berechnet deshalb zur Ladezeit einen absoluten Pfad, was funktioniert, weil content.config.ts ausgeführter Code und keine Datendatei ist. Auf dieser Nahtstelle sitzt die ganze sources-Kurzform.

#Warum es so gebaut ist

Die Alternative ist eine Starter-Vorlage: nuxi init, und das Theme ist nun eine Kopie in deinem Repository. Das gibt völlige Freiheit und keinen Upgrade-Pfad — jede Verbesserung am Theme ist ein Diff, das jemand von Hand anwenden muss. Eine Ebene dreht das um: Du erbst Verbesserungen und zahlst nur dort, wo du widersprochen hast.

Festgezurrt wird das durch die öffentliche Oberfläche. Eine Komponente, eine Seite oder ein app.config-Schlüssel, den du überschreiben kannst, ist ein Name, von dem du abhängst — einen davon umzubenennen ist deshalb eine brechende Änderung der Ebene, und genau das dokumentiert die Referenz.