Layers and overriding

duxt is a layer, not a template. You extend it, and every file it ships becomes overridable: put a file of the same name in your own project and Nuxt resolves yours first. Nothing is copied into your repository, so an upgrade is a version bump rather than a merge.

#What that means in practice

The order is deliberate: the first three are progressively larger commitments, and a component you replace is a component you now maintain. See Override the theme.

#What it takes away

A layer never knows the project standing on it. Two consequences a consumer feels:

• @ is yours, not the layer's. The alias belongs to whoever extends duxt, so the layer's own imports use @duxt instead. Yours keeps pointing at your app/.
• A collection resolves against the layer, not against you. Content records each collection's root as the layer that declared it, so a relative cwd in duxt's own config would point into duxt. The layer therefore computes an absolute path at load time — which works because content.config.ts is executed code rather than a data file, and that seam is what the whole sources shorthand sits on.

#Why it's built this way

The alternative is a starter template: nuxi init, and the theme is now a copy inside your repository. That gives total freedom and no upgrade path — every improvement to the theme is a diff someone has to apply by hand. A layer inverts it: you inherit improvements, and you pay only where you disagreed.

What pins this down is the public surface. A component, page or app.config key you can override is a name you depend on, so renaming one is a breaking change of the layer — which is what the reference documents.