\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_",[2873,2876],{"name":2874,"color":2875},"enhancement","a2eeef",{"name":2877,"color":2878},"triage","ffffff",4138,"✨ Feature Request: Add `\u003CDynamicRenderer>` component for config-driven UI rendering","2025-05-12T16:36:30Z","https://github.com/nuxt/ui/issues/4138",0.72745526,{"description":2885,"labels":2886,"number":2892,"owner":2863,"repository":2863,"state":2865,"title":2893,"updated_at":2894,"url":2895,"score":2896},"### Describe the feature\n\nNuxt and its great, out-of-the-box DX are really enjoyable. However, I still prefer explicit imports over automatic ones, with exception for very well-known utilities and composables; such as the ones exposed by Vue's core.\n\nWhile configuring Nuxt to disable the auto-importing of almost everything, I noticed the API isn't really intuitive and could be improved. The problem is that in addition to having set `imports: { autoImport: false }`, we have to explicitly disable component auto-imports using `components: false` or `components: { dirs: [] }`. Even though everything is documented well, having to separately disable component auto-imports feels like an extra, not-really-obvious step. TBH, this isn't a big deal. However, things get worse when it comes to not just disabling auto-imports, but rather customizing it.\n\nI wanted to disable all auto-imports, and only have the presets of Vue & Vitest auto-imported. Unfortunately, the API isn't flexible enough to let me do something like this and call it a day:\n```ts\nimports: {\n autoImport: 'presets', // Boolean | 'presets'\n presets: ['vitest', /* Vue's preset seems to be included by default. */],\n},\n```\n\nSo, I came up with this solution by playing around with different `imports` hooks:\n```ts\n// Disable auto-importing custom components, composables, and utilities.\ncomponents: {\n dirs: [],\n},\nimports: {\n presets: ['vitest'],\n},\nhooks: {\n 'imports:extend': (imports) => {\n imports.length = 0;\n },\n}, \n```\n\n\u003Cbr />\nI'd really appreciate it if the team considers a more flexible and intuitive API.\n\n### Additional information\n\n- [ ] Would you be willing to help implement this feature?\n- [ ] Could this feature be implemented as a module?\n\n### Final checks\n\n- [x] Read the [contribution guide](https://nuxt.com/docs/community/contribution).\n- [x] Check existing [discussions](https://github.com/nuxt/nuxt/discussions) and [issues](https://github.com/nuxt/nuxt/issues).",[2887,2889],{"name":2874,"color":2888},"8DEF37",{"name":2890,"color":2891},"pending triage","E99695",29275,"Better API for Auto Imports Customization","2024-10-08T08:40:01Z","https://github.com/nuxt/nuxt/issues/29275",0.73503286,{"description":2898,"labels":2899,"number":2905,"owner":2863,"repository":2864,"state":2865,"title":2906,"updated_at":2907,"url":2908,"score":2909},"### Environment\n\n- Operating System: Darwin\n- Node Version: v22.11.0\n- Nuxt Version: 3.16.0\n- CLI Version: 3.22.5\n- Nitro Version: 2.11.6\n- Package Manager: pnpm@9.15.4\n- Builder: -\n- User Config: modules, devtools, app, css, runtimeConfig, future, compatibilityDate, telemetry, eslint\n- Runtime Modules: @nuxt/ui-pro@3.0.0, @nuxt/eslint@1.0.1, @vueuse/nuxt@12.5.0, @nuxt/image@1.9.0\n- Build Modules: -\n\n### Is this bug related to Nuxt or Vue?\n\nNuxt\n\n### Version\n\nv3\n\n### Reproduction\n\nJust use `UAvatar` with `size=\"md\"`\n\n### Description\n\nHey,\n\nThe sizing and padding of UAvatar espicaly when fallback alt is being used does not look right on v3. See below same component first one on v2, second on v3 (yes it can be changed using config, but dont think this is good as a sane default. Issue also visible in UAvatarColorComponent on ui3 site light mode with vue logo)\n\n\u003Cimg width=\"712\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/0b9c4827-9078-4064-bace-5d724df24b86\" />\n\n\u003Cimg width=\"712\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/0a9f273f-cb27-4824-ac2f-6497980294ec\" />\n\n### Additional context\n\n_No response_\n\n### Logs\n\n```shell-script\n\n```",[2900,2903,2904],{"name":2901,"color":2902},"bug","d73a4a",{"name":2860,"color":2861},{"name":2877,"color":2878},3558,"Padding and Sizing on UAvatar","2025-03-13T13:44:50Z","https://github.com/nuxt/ui/issues/3558",0.7399114,{"description":2911,"labels":2912,"number":2913,"owner":2863,"repository":2914,"state":2915,"title":2916,"updated_at":2917,"url":2918,"score":2919},"This way of overriding options (using spread operator):\r\nhttps://github.com/nuxt-community/module-test-utils/blob/2801ebd478d54e97d95310bbfbd69e642223f363/lib/setup.js#L13-L16\r\nis often very limiting because it makes it impossible to override particular property of an object that has other properties.\r\n\r\nFor example, if we try to override one property from object:\r\n```\r\n{\r\n i18n: {\r\n a: 1,\r\n b: 2,\r\n c: 3,\r\n }\r\n}\r\n```\r\nwith:\r\n```\r\nconst override = {\r\n i18n: {\r\n b: 4\r\n }\r\n}\r\n```\r\nthen that will override whole `i18n` object, leaving just property `b`.\r\n\r\nThis module should rather use something like this:\r\n```\r\nconst deepMerge = require('deepmerge')\r\nconst options = deepMerge.all([options, override])\r\n```\r\n(This would probably be a breaking change if one relied on previous behavior)",[],270,"test-utils","closed","Inflexible nuxt options override","2023-12-02T00:13:07Z","https://github.com/nuxt/test-utils/issues/270",0.7153628,{"description":2921,"labels":2922,"number":2924,"owner":2863,"repository":2864,"state":2915,"title":2925,"updated_at":2926,"url":2927,"score":2928},"Related #196 \n\n| Alias | Name | Version |\n| ----- | ------------------------------------------- | --------------- |\n| ui | [nuxt/ui][nuxt-ui-href] | v3.0.0-alpha.10 |\n| tw | [tailwindcss][tailwindcss-href] | v4.0.0-beta.8 |\n| tv | [tailwind-variants][tailwind-variants-href] | v0.3.0 |\n| tm | [tailwind-merge][tailwind-merge-href] | v2.6.0 |\n| uno | [unocss][unocss-href] | v0.65.3 |\n\n**ui internally uses tv to flexibly generate component class names. tv internally uses tm to merge classes with the same effect (e.g., `p-2 p-4` --> `p-4`), and finally uses tw to recognize class names and generate style classes.**\n\n**After examining tv and tm, it became apparent that they don't strongly depend on tw, which opens up the possibility of replacing the final style generation step with uno.**\n\n\u003Cdetails>\n\u003Csummary>## tw Prefix Attempt (Optional)\u003C/summary>\n\nInitially, the idea was to limit tw to ui internals and uno for user usage. With tw's [prefix][tw-prefix-href] feature, the class rules became simpler. **However, ui internally (v3.0.0-alpha.10) doesn't yet support passing tw prefix configuration**, so let's first make ui support tw prefixes.\n\n### Understanding tv Variants\n\nTo add prefixes, we need to analyze the data structure that tv accepts.\n\n#### Regular Variants\n\n```ts\n import { tv } from 'tailwind-variants';\n\n tv({\n variants: {\n foo: {\n foo_val: 'px-2', // or ['pxx-2', ...], be the same, class / className\n },\n }\n })({ foo: 'foo_val' })\n```\n\n#### Boolean Variants (Including true/false keys)\n\n```ts\n tv({\n variants: {\n foo: {\n true: 'px-2',\n false: 'py-2',\n }\n }\n })({ foo: true, })\n```\n\n#### Compound Variants (Intersection between variants)\n\n```ts\n tv({\n variants: {\n foo: {\n foo_val: 'px-2',\n foo_val2: 'px-2',\n },\n bar: {\n true: 'px-2',\n false: 'py-2',\n },\n },\n compoundVariants: [\n {\n foo: 'foo_val', // or ['foo_val', 'foo_val2', ]\n bar: true,\n class: 'text-white', // You can also use \"className\" as the key\n }\n ],\n })({ foo: true, })\n```\n\n#### Responsive Variants (Device screen sizes)\n\n```ts\n tv({\n variants: {\n foo: {\n foo_val: 'px-2',\n foo_val2: 'px-4',\n },\n }\n },\n {\n responsiveVariants: ['sm', 'md'] // or `true` for all\n })({ \n foo: {\n initial: 'foo_val',\n sm: 'foo_val',\n md: 'foo_val2',\n }\n })\n```\n\n#### Slot Variants (Combining above variants with slots)\n\n```ts\n tv({\n slots: {\n slot_a: 'mx-2',\n slot_b: 'mx-2',\n },\n compoundSlots: [\n {\n slots: ['slot_a', 'slot_b', ], \n class: '',\n foo: 'foo_val', // for all slot while variant is missing\n },\n ],\n variants: {\n foo: {\n foo_val: {\n slot_a: 'px-2',\n }\n },\n bar: {\n true: {\n slot_a: 'mx-2'\n },\n false: {\n slot_a: 'mx-0'\n },\n },\n },\n compoundVariants: [\n {\n foo: 'foo_val',\n bar: true,\n class: {\n slot_a: '',\n }\n }\n ],\n {\n responsiveVariants: ['sm', 'md'] // or `true` for all\n }\n })({ \n foo: {\n initial: 'foo_val',\n sm: 'foo_val',\n md: 'foo_val2',\n }\n }) // --> { foo_slot, bar_slot, }\n```\n\n### Summary\n\nAfter adding prefix functionality locally (#3009 ) and configuring tw prefix (while installing uno to handle non-prefix classes in the playground for page styling), **practical usage revealed some unavoidable conflicts, such as at-rule usage. Additionally, this approach doesn't effectively prevent files from being processed twice (by both tw & uno)**. Therefore, let's try a different approach: remove tw completely and use UnoCSS for everything!\n\n\u003C/details>\n\n## Modifying ui\n\n### Disabling tw Plugin\n\nRemove `@tailwindcss/vite` installation handling from ui internals.\nRemove tw imports and specific configurations from ui playground.\n\n### Introducing uno\n\nFor [nuxt](https://unocss.dev/integrations/nuxt) | [vite](https://unocss.dev/integrations/vite)\n\nAlso, [Style Reset](https://unocss.dev/guide/style-reset) can be applied as needed.\n\n**IMPORTANT: Include @nuxt/ui files**\n\n```ts\nexport default defineConfig({\n presets: [\n presetUno(),\n ],\n content: {\n pipeline: {\n include: [\n // the default\n /\\.(vue|svelte|[jt]sx|mdx?|astro|elm|php|phtml|html)($|\\?)/,\n // IMPORTANT include @nuxt/ui files\n /\\.nuxt\\/ui\\//,\n ]\n }\n }\n})\n```\n\n## Primitive Variables\n\nuno doesn't generate primitive variables like tw does (e.g., `--color-green-500`, `--text-lg`, `--radius-md`, etc.), but ui internally needs these variables.\n\n**For now, we'll directly copy the primitive variables from tw's normal loaded to local.**\n\n## Rule Inconsistencies\n\n**There are must more undiscovered issues**\n\n### Ring\n\nIn uno, the default `ring` width is 3px, different from tw's 1px.\n\n**Solution:**\n\n```ts\n shortcuts: {\n ring: 'ring-1'\n },\n```\n\n### Color Opacity\n\ntw internally uses [color-mix](https://developer.mozilla.org/zh-CN/docs/Web/CSS/color_value/color-mix), allowing direct opacity settings for color variables.\nCurrently, uno doesn't support this directly.\n\ntw: `class=\"bg-[var(--color-primary)]/20\"` ✓\nuno: `class=\"bg-[var(--color-primary)]/20\"` ✕\nuno: `class=\"bg-[rgb(255,5,5)]/20\"` ✓\n\n```css\n:root {\n --color-primary: rgb(255, 5, 5);\n}\n```\n\nAfter observing ui usage, uno rules were added:\n\nuno: `class=\"bg-[var(--ui-primaey)]/20\"` ✓\nuno: `class=\"hover:bg-[var(--ui-primaey)]/75\"` ✓\n\n**Solution:**\n\n```ts\n rules: [\n [/(?:([^:\\s]+):)?bg-.*?\\[(var\\(--[^-]+-[^)]+\\))\\]\\/(\\d+)/, function* ([, modifier, color, alpha], { symbols }) {\n yield {\n background: `color-mix(in oklab, ${color} ${alpha}%, transparent)`\n }\n if (modifier) {\n yield {\n [symbols.selector]: selector => `${selector}:${modifier}`,\n background: `color-mix(in oklab, ${color} ${alpha}%, transparent)`\n }\n }\n }],\n [/(?:([^:\\s]+):)?text-.*?\\[(var\\(--[^-]+-[^)]+\\))\\]\\/(\\d+)/, function* ([, modifier, color, alpha], { symbols }) {\n yield {\n color: `color-mix(in oklab, ${color} ${alpha}%, transparent)`\n }\n if (modifier) {\n yield {\n [symbols.selector]: selector => `${selector}:${modifier}`,\n color: `color-mix(in oklab, ${color} ${alpha}%, transparent)`\n }\n }\n }]\n ],\n```\n\n---\n\nNow, let's run the playground! ~\n\n## Notes\n\n### tm's handling of tw and uno exclusive rules yields unexpected results\n\ntw doesn't directly support units (px, em, ...) like `text-Xpx`, requiring `text-[Xpx]` instead.\n\n- `text-md text-[20px]` --> `text-[20px]`\n- `text-md text-20px` --> `text-md text-20px`\n- `text-16px text-20px` --> `text-20px`\n- `text-[16px] text-[20px]` --> `text-[20px]`\n\n**When using ui, it's recommended to pass classes that tw can also parse.**\n\n[Commits · byronogis/ui](https://github.com/byronogis/ui/commits/test/use-unocss/)\n\n---\n\n\n[nuxt-ui-href]: https://ui3.nuxt.dev\n[tailwindcss-href]: https://tailwindcss.com/docs/v4-beta\n[tailwind-variants-href]: https://www.tailwind-variants.org/\n[tailwind-merge-href]: https://github.com/dcastil/tailwind-merge\n[unocss-href]: https://unocss.dev/\n[tw-prefix-href]: https://tailwindcss.com/docs/v4-beta#using-a-prefix\n",[2923],{"name":2857,"color":2858},3011,"[Attempt] Exploring the Coexistence of Nuxt UI v3 and UnoCSS","2025-05-10T19:47:10Z","https://github.com/nuxt/ui/issues/3011",0.71569747,{"labels":2930,"number":2935,"owner":2863,"repository":2863,"state":2915,"title":2936,"updated_at":2937,"url":2938,"score":2939},[2931,2932],{"name":2874,"color":2888},{"name":2933,"color":2934},"2.x","d4c5f9",4430,"Multi-variant Nuxt App","2023-01-22T15:50:48Z","https://github.com/nuxt/nuxt/issues/4430",0.7284009,{"description":2941,"labels":2942,"number":2943,"owner":2863,"repository":2863,"state":2915,"title":2944,"updated_at":2945,"url":2946,"score":2947},"### Describe the feature\n\nI am currently in the situation that I have a kind of \"base project\" and another one which wants to overwrite components on a large scale.\r\n\r\nTo overwrite these components, I currently only see the possibility to use Nuxt 3 Layers. (Nuxt auto import does not support overwriting with the help of the \"level\" attribute anymore.\r\n\r\nSince this would currently lead to major rebuilds in my projects (extraction of types etc to reuse them in the other project), I would have liked an easier option.\r\n\r\nIs there a known one?\n\n### Additional information\n\n- [ ] Would you be willing to help implement this feature?\n- [ ] Could this feature be implemented as a module?\n\n### Final checks\n\n- [X] Read the [contribution guide](https://v3.nuxtjs.org/community/contribution).\n- [X] Check existing [discussions](https://github.com/nuxt/framework/discussions) and [issues](https://github.com/nuxt/framework/issues).",[],15839,"Nuxt3: component override without nuxt layers","2023-01-20T14:16:41Z","https://github.com/nuxt/nuxt/issues/15839",0.7302312,{"labels":2949,"number":2952,"owner":2863,"repository":2863,"state":2915,"title":2953,"updated_at":2954,"url":2955,"score":2956},[2950,2951],{"name":2874,"color":2888},{"name":2933,"color":2934},10299,"Layout options","2025-03-12T16:25:33Z","https://github.com/nuxt/nuxt/issues/10299",0.73104084,{"description":2958,"labels":2959,"number":2967,"owner":2863,"repository":2863,"state":2915,"title":2968,"updated_at":2969,"url":2970,"score":2971},"### Describe the feature\r\n\r\nCurrently it is not possible to have a server only component or client only component when importing them explicitly (such as `import Client from '@/Client.client.vue'` or `import ServerComp from \"../../ServerComp.server.vue\"`.\r\nTransforming them when explicitly imported makes more sense \r\n\r\nThis is a feature/fix that could possibly break some apps so it may be better to have it in nuxt 4.\r\n\r\n### Additional information\r\n\r\n- [X] Would you be willing to help implement this feature?\r\n- [ ] 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).",[2960,2961,2964],{"name":2874,"color":2888},{"name":2962,"color":2963},"3.x","29bc7f",{"name":2965,"color":2966},"🍰 p2-nice-to-have","0E8A16",27114,"Transform components imported by explicit import","2024-06-28T10:40:46Z","https://github.com/nuxt/nuxt/issues/27114",0.73153996,["Reactive",2973],{},["Set"],["ShallowReactive",2976],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$f_k1yS0gYdjrfCMdaADhDQDxpuelppV3EQ1UqIcArHyQ":-1},"/nuxt/ui/3382"]