Layers/Extends Support Tracker

Nuxt layers are a powerful feature that you can use to share and reuse partial Nuxt applications within a monorepo, or from a git repository or npm package.

Docs:

• Usage: https://nuxt.com/docs/getting-started/layers
• Authoring: https://nuxt.com/docs/guide/going-further/layers

This issue is used to track the progress of enhancements and known issues in the roadmap.

Features:

• Initial support (#3008)
• components/ dir (#3108)
• composables/ dir (https://github.com/nuxt/framework/pull/3423)
• plugins/ dir (https://github.com/nuxt/framework/pull/3462)
• server/ dir (#3673) [need refactor for nitropack]
• pages/ dir (#3783)
• middleware/ dir (#3783)
• layouts/ dir (through https://github.com/nuxt/framework/pull/3610)
• public/ dir (nitropack pending but could be workaround to pick one layer)
• app/ dir (app/router.options) (https://github.com/nuxt/framework/pull/3939)
• app.vue (https://github.com/nuxt/framework/pull/6228)
• hooks for extending dirs
• Usage and authoring docs #9405
• Named layer aliases
• Merge hook config key
• install cloned dependencies (https://github.com/unjs/c12/issues/51)
• Multi-app support (TBA)

Bugs:

• Auto imports for nitro layers (#9384)

[Tahul]

Hey there 👋

We’ve made a review of extends feature with @kevinmarrec so I can document it!

I would like to brainstorm few ideas with you, before beginning any changes.

Aside from these points, we’ve tried the extends feature together with @kevinmarrec and it went really well!

I will start creating a PR to document this with appropriate examples as you mentioned in the first message. 🙂

Extends configuration

With the current extends implementation, once you pass a path to be extended, Nuxt will try to grab every available feature from this extended directory.

It is really great to have such behavior as it makes extends a real plug & play feature, but having some flexibility over how we do extend our project would be really great.

What I suggest is to have a similar way to configure your extends as components does:

defineNuxtConfig({
   extends: [
      './base', // Would be fully extended
      {
            path: './ui',
            middleware: false, // Would skip middleware extending
            pages: false, // Would skip pages extending
            // All of the rest are set to `true` by default
        }
   ]
})

That would maybe include a PR to c12 package in order to support this.

Extends pages prefixing

One cool feature would be to be able to rewrite the base path of pages from an extend target.

Let’s say you extend your project from a blog theme that has default pages exposed.

The blog theme might expose index pages and such from the root of its pages directory, so that would be overwritten by your own website.

What you might want then is to have these blog pages nested under a /blog prefix in your project.

We could use the previous configuration object to specify this:

defineNuxtConfig({
   extends: [
        './base', // Pages would be merged with project-level pages
        {
            path: './blog',
            pagesPrefix: '/blog' // Pages would be nested under `/blog` route prefix
        }
   ]
})

Low to high instead of high to low priority management

One thing we noticed during the review of extends is that currently the priority is handled in a high to low manner:

defineNuxtConfig({
   extends: [
        './ui', // This will override `./base`
        './base'
   ]
})

This is nitpicking but I think this is an opposite pattern of what we commonly expect from extends features.

For instance files like .eslintrc has this “last has highest precedence” as convention.

WDYT @danielroe @pi0 @Atinux @kevinmarrec ? 😄

[fanckush]

@pi0 will /assets also be supported?