\n \u003C/template>\n\n \u003Ctemplate v-else>\n \u003CDynamicRenderer :config=\"slotContent\" :key=\"slotContent.name || slotName\" />\n \u003C/template>\n \u003C/template>\n \u003C/component>\n\u003C/template>\n```\n\n\n\n#### `index.vue`\n```vue\n\u003Cscript setup lang=\"ts\">\nimport { UButton, UCard, UContainer, UForm, UFormField, UInput } from '#components'\n\nconst config = {\n component: UContainer,\n class: 'h-screen flex justify-center items-center',\n slots: {\n default: [\n {\n component: UCard,\n slots: {\n default: [{\n component: UForm,\n class: 'space-y-4',\n slots: {\n default: [\n {\n component: UFormField,\n label: 'Username',\n name: 'username',\n required: true,\n slots: {\n default: [\n {\n component: UInput,\n placeholder: 'Enter Username',\n value: 'hh'\n }\n ]\n }\n },\n {\n component: UFormField,\n label: 'Password',\n name: 'password',\n required: true,\n slots: {\n default: [\n {\n component: UInput,\n type: 'password',\n placeholder: 'Enter Password',\n value: 'hh'\n }\n ]\n }\n },\n {\n component: UButton,\n label: 'Login',\n icon: 'i-lucide-user',\n variant: 'soft',\n type: 'submit',\n block: true\n }\n ]\n }\n }]\n }\n }\n ]\n }\n}\n\u003C/script>\n\n\u003Ctemplate>\n \u003CDynamicRenderer :config=\"config\" />\n\u003C/template>\n```\n\n### Result \n\n\nIt would also be great if using this approach could eliminate the need to manually import components like:\n\n```ts\nimport { UButton, UCard, UContainer, UForm, UFormField, UInput } from '#components'\n```\n\nand instead rely on automatic resolution by the renderer itself.\n\nThanks for your work on Nuxt UI – it’s a fantastic toolkit!\n\n### Additional context\n\n_No response_",[2856,2859],{"name":2857,"color":2858},"enhancement","a2eeef",{"name":2860,"color":2861},"triage","ffffff",4138,"nuxt","ui","open","✨ Feature Request: Add `\u003CDynamicRenderer>` component for config-driven UI rendering","2025-05-12T16:36:30Z","https://github.com/nuxt/ui/issues/4138",0.7197711,{"description":2871,"labels":2872,"number":2878,"owner":2863,"repository":2863,"state":2865,"title":2879,"updated_at":2880,"url":2881,"score":2882},"### Describe the feature\r\n\r\nI have been trying to configure auto-imports for a library of web components, so that i can minimize bundle size without having to manually add imports.\r\n\r\nI tried creating a module like this:\r\n\r\n```ts\r\nimport { defineNuxtModule, addComponent } from 'nuxt/kit'\r\n\r\nexport default defineNuxtModule({\r\n meta: {\r\n name: 'my-components',\r\n compatibility: {\r\n nuxt: '^3.0.0',\r\n },\r\n },\r\n\r\n setup() {\r\n // From the runtime directory\r\n addComponent({\r\n name: 'MyButton',\r\n kebabName: 'my-button',\r\n mode: 'client',\r\n filePath: \"@my/web-components/Button.js\",\r\n })\r\n },\r\n})\r\n```\r\n\r\nHowever, this does not work as `addComponent` (or something downstream of it) expects there to be a vue component at the given path. the problem would exist just the same if I had a web component relative to the module (i.e. not from npm)\r\n\r\nI am wondering if there is any scope to extend `addComponent`/component auto-import behavior to support web components. Since web components typically register themselves, the desired output would be a side-effect import wherever usage of `my-button` was detected. something like this:\r\n\r\n```ts\r\n// rather than this\r\nimport Button from \"@my/web-components/Button.js\"\r\n// we would have this\r\nimport \"@my/web-components/Button.js\"\r\n```\r\n\r\nMy first thought was to add a `sideEffectOnly: boolean` option to `addComponent` as a flag to indicate this is the desired behavior, but i don't think that composes well with other existing options (e.g. what does it mean to have `mode: \"server\"` with `sideEffectOnly: true`?). Therefore perhaps the best option would be a new value for `mode`, since (right now) web components are implicitly client-side. \r\n\r\nI'm sure it's possible to build this behavior outside of nuxt with some custom transforms etc, but i imagine a comprehensive solution would end up recreating most, if not all, of nuxt's existing mechanisms for scanning/importing/tree-shaking components.\r\n\r\nSuch an addition would be useful not just in my use case, but for all web component libraries. Additionally, many WC libraries publish a [manifest of components](https://github.com/webcomponents/custom-elements-manifest) they contain, meaning a generic nuxt module could be written which accepts the manifest as an input, and dynamically calls `addComponent` for each web component found. \r\n\r\nIn summary, my proposal is something like:\r\n\r\n```ts\r\naddComponent({\r\n name: 'my-button',\r\n mode: 'web-component', // the specific value is up for debate\r\n filePath: \"@my/web-components/Button.js\",\r\n})\r\n```\r\n\r\n### Additional information\r\n\r\n- [X] Would you be willing to help implement this feature?\r\n- [X] Could this feature be implemented as a module?\r\n\r\n### Final checks\r\n\r\n- [X] Read the [contribution guide](https://nuxt.com/docs/community/contribution).\r\n- [X] Check existing [discussions](https://github.com/nuxt/nuxt/discussions) and [issues](https://github.com/nuxt/nuxt/issues).",[2873,2875],{"name":2857,"color":2874},"8DEF37",{"name":2876,"color":2877},"discussion","538de2",25528,"nuxt/kit: ability to configure web components for auto-import","2024-06-30T11:05:58Z","https://github.com/nuxt/nuxt/issues/25528",0.72098637,{"description":2884,"labels":2885,"number":2891,"owner":2863,"repository":2864,"state":2892,"title":2893,"updated_at":2894,"url":2895,"score":2896},"### Description\n\nSay I want to use `\u003CUPageHero />` and populate the contents from a .yml file, it would be cool if i could do something in my `content.config.ts` like:\n\n```ts\nimport { ZodPageHero } from '@nuxt/ui'\n\nexport default defineContentConfig({\n collections: {\n page: defineCollection({\n type: 'page',\n schema: z.object({\n hero: ZodPageHero,\n }),\n })\n})\n```\n\n\n\n\n### Additional context\n\n_No response_",[2886,2887,2890],{"name":2857,"color":2858},{"name":2888,"color":2889},"v3","49DCB8",{"name":2860,"color":2861},4263,"closed","provide zod schemas for nuxt content collections","2025-05-30T20:56:17Z","https://github.com/nuxt/ui/issues/4263",0.6144646,{"description":2898,"labels":2899,"number":2905,"owner":2863,"repository":2863,"state":2892,"title":2906,"updated_at":2907,"url":2908,"score":2909},"In Nuxt 3, we have introduced a new package `@nuxt/schema` that holds types, defaults, and documentation for all build-in configurations for Nuxt and from one source using [untyped](https://github.com/unjs/untyped). In comparation with Nuxt 2, these were separately maintained, often with inconsistencies. This new system is also designed to be future proof to be able to **manage configuration via UI** using generated (JSON)Schema files and also **runtime validation** to notice any usage issues.\r\n\r\nFor Nuxt modules, it is already possible to extend a typescript interface `ModuleOptions` to provide types, however it has same limitations of Nuxt 2 era. We have introduced new `schema` in new `@nuxt/kit` module definition system however it became unused.\r\n\r\nWith the introduction of Nuxt Layers, themes can also now require some specific configuration. Most importantly for configuring `runtimeConfig` and app config (either via `appConfig` or `app.config`)\r\n\r\nFor this, we can use the same tooling (untyped) as a built-in feature to allow providing custom configuration schemas from Nuxt layers and modules (also directly from a Nuxt project). Benefiting from most possibilities (note 1) we have already for core config.\r\n\r\nWe have made an experiment [nuxt-experiments/nuxt-config-schema](https://github.com/nuxt-experiments/nuxt-config-schema) that is now almost ready to be moved into a core experiment, allowing to make it better usable. It is possible to provide custom config schema for nuxt projects in different ways:\r\n\r\n- Using `nuxt.schema.ts` in main Nuxt project or a layer\r\n- Using `$schema` key in `nuxt.config`\r\n- Extend `nuxt.options.$schema` for modules\r\n- Extend schema using `schema:extend`, `schema:resolved` and `schema:beforeWrite` for modules (note 2)\r\n- Use `schema` in `defineNuxtModule` (recommended way for modules. also supports defaults)\r\n\r\nThe output will be in `.nuxt` directory and initially mainly usable for the Augmentation of types and custom purposes such as UI.\r\n\r\n\r\n**Notes:**\r\n\r\nnote 1: Since development and trial of the experimental module, one particularly important point we found is that, unlike the core usage, mixing schema with defaults is not a good practice. We can only merge schema after modules are setup and it is too late for them to **re**apply new defaults and do their config handling logic and also it makes it much harder to merge runtime configuration such as `app.config` since custom merger logic resides in runtime while schema is in the build-time namespace and merging strategy is different.\r\n\r\nnote 2: We have introduced two separate hooks. `extend`/`resolve` as main way to extend schema just after all modules are initialized and before core or any other place tries to use schema and another `beforeWrite` as last resort (less recommended) for when a module needs to extend schema based on build aftertifacts coming from webpack, rollup or nitro's rollup step and it mainly and only affects the written files.\r\n\r\n\r\n\r\n\r\n\r\n",[2900,2901,2902],{"name":2857,"color":2874},{"name":2876,"color":2877},{"name":2903,"color":2904},"3.x","29bc7f",15592,"Custom config schema","2023-04-07T01:47:49Z","https://github.com/nuxt/nuxt/issues/15592",0.6727549,{"description":2911,"labels":2912,"number":2914,"owner":2863,"repository":2864,"state":2892,"title":2915,"updated_at":2916,"url":2917,"score":2918},"### For what version of Nuxt UI are you suggesting this?\n\nv2.x\n\n### Description\n\nHi,\n\nWould it be possible to add an export of all components ?\n\nSomething like:\n\n```js\nexport * from './components'\n```\n\n### Additional context\n\nI'm trying to display a form field according to its value type (ex: boolean => checkbox, number => range ...).\n\nSadly, it looks like in composition API, one cannot use string for `\u003Ccomponent>` `:is` prop.\n\n```vue\n\u003Ctemplate>\n \u003C!-- This doesn't work -->\n \u003Ccomponent :is=\"typeof value === 'boolean' ? 'u-checkbox' : 'u-input'\" />\n\u003C/template>\n```\n\nApparently, you have to pass the component itself, but I'm unable to import components from Nuxt UI:\n\n```vue\n\u003Cscript setup>\n// This doesn't work\nimport { UCheckbox, UInput } from '@nuxt/ui';\n\u003C/script>\n\n\u003Ctemplate>\n \u003Ccomponent :is=\"typeof value === 'boolean' ? UCheckbox : UInput\" />\n\u003C/template>\n```\n\nI can use `v-if` as a workaround, but it forces me to duplicate a lot of props (class, listeners, model ...) on each component.",[2913],{"name":2857,"color":2858},2891,"Export of every components","2025-01-13T16:32:50Z","https://github.com/nuxt/ui/issues/2891",0.70475566,{"labels":2920,"number":2923,"owner":2863,"repository":2863,"state":2892,"title":2924,"updated_at":2925,"url":2926,"score":2927},[2921,2922],{"name":2857,"color":2874},{"name":2903,"color":2904},12790,"Support `global: false` for components","2023-01-19T16:35:12Z","https://github.com/nuxt/nuxt/issues/12790",0.7072851,{"description":2929,"labels":2930,"number":2934,"owner":2863,"repository":2863,"state":2892,"title":2935,"updated_at":2936,"url":2937,"score":2938},"In every component or page we create we end up having tons of `import \"components/component/SomeComponent.vue\"` states for basic elements like regions, layouts, grids & columns. Is there a way in nuxt to define those components globally so they are known in subcomponents? Something like `import \"components/frame/Frame.vue\"` that contains the imports for regions, layouts, grids & columns. \n\n\u003C!--cmty-->\u003C!--cmty_prevent_hook-->\n\u003Cdiv align=\"right\">\u003Csub>\u003Cem>This question is available on \u003Ca href=\"https://nuxtjs.cmty.io\">Nuxt.js\u003C/a> community (\u003Ca href=\"https://nuxtjs.cmty.io/nuxt/nuxt.js/issues/c363\">#c363\u003C/a>)\u003C/em>\u003C/sub>\u003C/div>",[2931],{"name":2932,"color":2933},"2.x","d4c5f9",421,"Define global components","2023-01-18T22:17:23Z","https://github.com/nuxt/nuxt/issues/421",0.70772505,{"description":2940,"labels":2941,"number":2946,"owner":2863,"repository":2863,"state":2892,"title":2947,"updated_at":2948,"url":2949,"score":2950},"### Environment\n\nNuxi 3.2.2 \r\n------------------------------\r\n- Operating System: `Windows_NT`\r\n- Node Version: `v18.14.1`\r\n- Nuxt Version: `3.2.2`\r\n- Nitro Version: `2.2.3`\r\n- Package Manager: `npm@9.3.1`\r\n- Builder: `vite`\r\n- User Config: `components`\r\n- Runtime Modules: `-`\r\n- Build Modules: `-`\r\n------------------------------\n\n### Reproduction\n\nReproduce Link: https://stackblitz.com/edit/github-tznxrd\r\n\r\n1. npx nuxi init demo\r\n2. cd demo\r\n3. npm install\r\n4. mkdir -p components/layouts\r\n5. edit nuxt.config.ts\r\n **nuxt.config.ts**\r\n ```\r\n export default defineNuxtConfig({\r\n components: [\r\n { path: '~/components/layouts', prefix: 'Special' },\r\n '~/components'\r\n ]\r\n })\r\n ```\r\n\r\n\r\n6. create **header.vue** under components/layouts\r\n ```\r\n \u003Ctemplate>\r\n \u003Cdiv>\r\n Header\r\n \u003C/div>\r\n \u003C/template>\r\n ```\r\n\r\n7. import header.vue in **app.vue**\r\n ```\r\n \u003Ctemplate>\r\n \u003Cdiv>\r\n \u003CHeader />\r\n \u003CNuxtWelcome />\r\n \u003C/div>\r\n \u003C/template>\r\n \r\n \u003Cscript>\r\n import Header from '~/components/layouts/header.vue';\r\n \u003C/script>\r\n ```\r\n\r\n\r\n8. npm run dev\r\n\n\n### Describe the bug\n\n[Vue warn]: Failed to resolve component: Header\r\nIf this is a native custom element, make sure to exclude it from component resolution via compilerOptions.isCustomElement. \n\n### Additional context\n\n_No response_\n\n### Logs\n\n_No response_",[2942,2943],{"name":2903,"color":2904},{"name":2944,"color":2945},"pending triage","E99695",19310,"If this is a native custom element, make sure to exclude it from component resolution via compilerOptions.isCustomElement.","2023-02-27T12:15:17Z","https://github.com/nuxt/nuxt/issues/19310",0.71148956,{"labels":2952,"number":2955,"owner":2863,"repository":2863,"state":2892,"title":2956,"updated_at":2957,"url":2958,"score":2959},[2953,2954],{"name":2857,"color":2874},{"name":2903,"color":2904},12962,"Type Support for Global Components (e.g. `\u003Cnuxt-link>`)","2023-01-19T16:39:56Z","https://github.com/nuxt/nuxt/issues/12962",0.71325743,{"description":2961,"labels":2962,"number":2965,"owner":2863,"repository":2863,"state":2892,"title":2966,"updated_at":2967,"url":2968,"score":2969},"- [x] Initial working version from [@nuxt/components](https://github.com/nuxt/components)\r\n- [x] `.dts` generation\r\n- [x] Decide about prefix\r\n- [x] Implement loader strategy (vite and webpack5) \r\n- [ ] Integrate with devtools\r\n\r\n### Discussion: Should we even have it with nuxt3?\r\n\r\nRelated tweet (https://twitter.com/youyuxi/status/1404795327144763398). I think that makes sense in many ways that auto-import is not that needed with new `\u003Cscript setup>` syntax and better VSCode integrations. But there are still some cases most notable, CMS/Content integrations that implicitly need global components. And also this gives possibility with nuxt devtools component playground\r\n\r\n### Discussion: Where to implement?\r\n\r\nIn `framework/packages/components` as a fork of `nuxt/components` and add by default in `nuxt3`\r\n\r\n### Discussion: Prefixing\r\n\r\nShould we use (by default) one level prefix `components/utils/bar/baz` => `BarBaz` or full prefix => `UtilsBarBaz` or not at all (`Baz`) by default (suggested by @Atinux). Second is much more future proof but less convenient for structuring components dir based on purpose (and atomic designs)",[2963,2964],{"name":2876,"color":2877},{"name":2903,"color":2904},11026,"Components Discovery","2023-01-19T14:46:30Z","https://github.com/nuxt/nuxt/issues/11026",0.7145133,["Reactive",2971],{},["Set"],["ShallowReactive",2974],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$flgGUetConR7uOT2QobccDk5Wp0A_Hp95mrriE1XsxQo":-1},"/nuxt/ui/4161"]