-
-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Layers/Extends Support Tracker #13367
Comments
Hey there 👋 We've made a review of 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 configurationWith the current It is really great to have such behavior as it makes 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 Extends pages prefixingOne 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 The blog theme might expose index pages and such from the root of its What you might want then is to have these blog pages nested under a 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 managementOne thing we noticed during the review of 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 WDYT @danielroe @pi0 @atinux @kevinmarrec ? 😄 |
Extends options What about using the array syntax for it since the first argument is required? defineNuxtConfig({
extends: [
'./base', // Pages would be merged with project-level pages
['./blog', { pages: { prefix: '/blog' } }],
]
}) I am personally not a big fan of array syntax though. If using the object syntax, I don't think that Low to hight makes sense actually, I cannot recall why we have the opposite order (Pooya may be able to answer) |
What about using defineNuxtConfig({
extends: [
'./base', // Pages would be merged with project-level pages
{
from: './blog',
pages: { prefix: '/blog' },
middleware: false
}
]
}) |
For both above points, changes need to be applied to |
Thanks for the feedback @Tahul @atinux @kevinmarrec 💚 Overriding by layer seems a good idea. I like both In order to disable scanning of a directory of a layer, I think we can reuse of Regarding prefixes, I made lots of thoughts since (nuxt/rfcs#30). Extend feature will be surely the basis for multi-app support but it is more complicated than you might imagine and too soon implemented in this stage. Usage of baseURL and Regarding the ordering convention, I guess we will keep it as is. defu@v6 is released to respect the same convention for joining arrays. Internally it makes implementation of multi-layer much more straightforward since we can simpy iterate and in next layers, ignore if a duplicate item exists (vs resolve and override with reverse manner). User wise, |
Hey, thank you a lot for your feedback @pi0 🙏 I noticed the existence of an additional file/directory inside Nuxt 3 structure: I saw there here: nuxt/framework#3485 & here. I think as these file/this directory contains data configuring the app, we should allow extending of this file aswell? I'm using |
Sure thing. Makes sense for supporting |
@pi0 will |
It fall into named layer aliases. |
Hey guys :) Really great feature! I already tried this, but it doesn't work. I guess because the config is already loaded at the time my module setup is processed:
|
@dm-heinze You can load and extend options in modules by modifying If I correctly get your idea, you want to make it easier for modules by simply following Nuxt convention for |
Can the extend feature be used for different themes that change some parts of the application layout? |
Can you please explain more @sawden? Two themes can provide or override composables and components of course used in layout. |
@pi0 I designed a small example to show what I mean: |
@SunSi12138 dependencies are still not auto-installed from layer. You need to install all your layer dependencies manually on your project. The Nuxt team is working on an auto-install for layers deps and it's being tracked here: unjs/c12#51 |
HI, I have three layers, one is for UI, one is for LOGIC and the last is for my main app. |
css files from base layer are added to the html head after the project css files. please see: stackblitz.com nuxt.config.ts:
base layer nuxt.config:
in the website source:
project.css should clearly be after base.css file(s) so that project can overwrite styles? |
How can I import a component? I have a component called ElementsIcon in my layer and I want to use this component in the h() function in my project. Like the following code: const icon = h(ElementsIcon, {
name: 'dismiss',
size: '20px',
'v-tooltip': { content: __('cancel order'), placement: 'bottom', distance: 12 },
onClick: () => {
onCancelOrder(row.id);
}
}); But I don't know how to import this component |
@hamedfaryabi You can import it from import { ElementsIcon } from '#components' But better to ask questions here https://github.com/nuxt/nuxt/discussions/categories/questions or in the Discord |
|
Now that unjs/c12#51 is closed, I'm so hyped for it to land on Nuxt. ♥ |
You can already do this! {
extends: [
["foobar", { install: true }]
]
} This is opt-in behavior until a while we can test all edge cases and optimize installation speeds. |
How do I overwrite layer plugins in my app? Currently, they are both valid, and even if the plugin name is specified, it cannot be overwritten
|
@baixiaoyu2997 I think this is a bug that was introduced in 3.9.0. Could you try in 3.8.3? |
I have a question regarding layers and typescript. If I put the following in declare global {
interface MyType {
attr1: string
}
}
export {}; And the following in declare global {
interface MyType {
attr2: string
}
}
export {}; If interface MyType {
attr1: string
attr2: string
} I find this incredibly useful, but wanted to ask whether this is intended behavior or whether I am using a weird hack - and whether there is a danger that this will stop working in the future? |
I don't think it's a weird hack. If you look inside the |
@pi0 / @danielroe I'm not sure what the progress is on "Named layer aliases", I created a Nuxt module that creates an alias per layer and made ~,@, etc aliases fall back from project down to each layer. I'm not sure if every case is covered but it works for our use cases. If you are interested, I'm happy to share. But I do belief this feature should exist native in Nuxt instead of a separate module. |
Hi @kjfranke , can you share it ? |
Any solution? |
Layers do not seem to install dev dependencies correctly. I created #26980 for this, and have now found a few other cases where people are saying that #19124 is still present (here, here, and here), and all of those cases are specifically dev dependencies. Runtime dependencies seem to work fine. Not sure what the repercussions would be of indiscriminately installing all dev dependencies from layers, but it does seem important that Nuxt modules at the very least are installed ( |
I commented on the issue you created. This seems like expected behavior: #26980 (comment) |
Yeah, I think you're right that at the moment it is expected behaviour - I shouldn't have called it a bug. However, I think it needs discussion, because right now it seems installing modules in a layer will make that layer unusable. I suspect this happens because:
|
I was able to have it done, by importing css for base layer in
and next instead of importing css in
Please see: https://stackblitz.com/edit/nuxt-starter-tcptzx?file=app.vue |
The same for scss: https://stackblitz.com/edit/nuxt-starter-orbtho?file=app.vue |
For anyone searching the module @kjfranke mentioned, it's located here: https://github.com/kjfranke/nuxt3-layer-alias For me it looks like a good option if you want to share and/or overwrite f.e. |
Waiting for multi app support |
Hey! Layers are amazing! Is there any possibility of using them with the content directory from @nuxt/content? Or somehow specifying which directories from the layers should be merged? Or this is a bad idea? Thank you! |
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:
This issue is used to track the progress of enhancements and known issues in the roadmap.
Features:
components/
dir ([Enhancement] Support extractCss in webpack 4 #3108)composables/
dir (feat!(nuxt3): extends support for composables/ directory framework#3423)plugins/
dir (feat(nuxt3): extends support for plugins/ directory framework#3462)server/
dir (Relative path in custom watchers #3673) [need refactor for nitropack]pages/
dir (Meta information missing in nested child page after nuxt generate #3783)middleware/
dir (Meta information missing in nested child page after nuxt generate #3783)layouts/
dir (through feat(nuxt3)!: enable using<NuxtLayout>
without pages integration framework#3610)public/
dir (nitropack pending but could be workaround to pick one layer)app/
dir (app/router.options
) (feat(nuxt3): extends support forapp/router.options
framework#3939)hook
config key: fix(nuxt): merge and apply layer hooks #24639Bugs:
The text was updated successfully, but these errors were encountered: