\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).",[3192,3194],{"name":3159,"color":3193},"8DEF37",{"name":3195,"color":3196},"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":3203,"labels":3204,"number":3208,"owner":3170,"repository":3171,"state":3209,"title":3210,"updated_at":3211,"url":3212,"score":3213},"### Description\n\nHi, \nI'm struggling to customize my components when using Nuxt UI within another Nuxt Module, I've search but cannot get it to work, tried with using app.config.ts like below and also within module.ts but no joy, would appreciate if someone could help out.\n\n\n```\nexport default defineAppConfig({\n ui: {\n button: {\n slots: {\n base: 'rounded-full font-semibold cursor-pointer'\n },\n },\n }\n})\n\n```\nMy module.ts file:\n\n```\nimport { defineNuxtModule, installModule, createResolver } from '@nuxt/kit'\n\nexport default defineNuxtModule\u003CModuleOptions>({\n meta: {\n name: 'my-module',\n configKey: 'myModule',\n },\n hooks: {\n 'nitro:config': (nitroConfig) => {\n const { resolve } = createResolver(import.meta.url)\n\n nitroConfig.publicAssets ||= []\n nitroConfig.publicAssets.push({\n dir: resolve('./runtime/images/'),\n maxAge: 60 * 60 * 24 * 365,\n })\n },\n },\n defaults: {},\n async setup(_options, _nuxt) {\n const { resolve } = createResolver(import.meta.url)\n\n\n await installModule('@nuxt/ui')\n await installModule('nuxt-svgo', {\n autoImportPath: resolve('./runtime/icons'),\n defaultImport: 'component',\n componentPrefix: 'i',\n })\n\n _nuxt.options.css.push(resolve('./runtime/style.css'))\n },\n})\n\n```",[3205,3206,3207],{"name":3181,"color":3182},{"name":3162,"color":3163},{"name":3168,"color":3166},3679,"closed","How to override components style globally when using within another Nuxt Module?","2025-06-11T10:32:59Z","https://github.com/nuxt/ui/issues/3679",0.67330956,{"description":3215,"labels":3216,"number":3224,"owner":3170,"repository":3171,"state":3209,"title":3225,"updated_at":3226,"url":3227,"score":3228},"### Description\n\nHi\n\nThis is the approach I took personally with my own ui framework and it works really nicely. \n\nBasically it would be amazing to be able to define project level themes (in the project level /themes dir perhaps). Inside here you’d have your theme name as the directory (this is how you reference the theme) and then inside there you add TV overrides. \n\n#### Project:\n\n```md\n/themes\n theme-a\n button.ts\n```\n\nThen at the ui.config level or at the component level the user can then set the theme, which sets the styles for the component. \n\n#### app.config:\n\n```ts\nui: {\n theme: “theme-a”, // would override all components \n components: {\n button: {\n theme: “theme-a” // would override button theme globally\n theme: {\n extend: true,\n theme: “theme-a” // merges theme-a with NuxtUI button theme\n }\n }\n }\n}\n```\n\nCan set theme at component level too. Also could introduce an api for extending base theme rather than replacing, meaning user wouldn’t provide overrides. \n\n```vue\n\u003CUButton theme=“theme-a”>button\u003C/UButton>\n```\n\nIt would be nice to be able to choose whether the theme extends the NuxtUI or replaces for that specific component or use on the component. \n\nPersonally I created a `createTheme` module which handle this for every component. Naturally the heavy lifting here uses vite imports for pulling in project themes, and TailwindVariants to do the cascading merging of tv objects. \n\nWould make NuxtUI unbeatable in terms of being able to customise and theme components. \n\n### Additional context\n\n_No response_",[3217,3218,3219,3222,3223],{"name":3159,"color":3160},{"name":3162,"color":3163},{"name":3220,"color":3221},"triage","ffffff",{"name":3165,"color":3166},{"name":3168,"color":3166},3393,"Set project level named themes","2025-06-18T09:01:54Z","https://github.com/nuxt/ui/issues/3393",0.68710643,{"description":3230,"labels":3231,"number":3236,"owner":3170,"repository":3171,"state":3209,"title":3237,"updated_at":3238,"url":3239,"score":3240},"### Description\n\nIs there a way to add custom props to a component for styling—similar to how variant works for buttons? I’d like to add variant support to FormField, but currently, it only supports size.\n\nMy main goal is to allow styling of components provided by my Nuxt module. Ideally, I want to define variants and extra props via app.config.ts. An alternative approach I'm thinking of is to offer per-component config options, similar to Nuxt UI, but managed separately from its config.",[3232,3233,3234,3235],{"name":3181,"color":3182},{"name":3162,"color":3163},{"name":3165,"color":3166},{"name":3168,"color":3166},4148,"Additional props like variants for styling","2025-08-20T02:08:47Z","https://github.com/nuxt/ui/issues/4148",0.70058006,{"description":3242,"labels":3243,"number":3246,"owner":3170,"repository":3171,"state":3209,"title":3247,"updated_at":3248,"url":3249,"score":3250},"### For what version of Nuxt UI are you suggesting this?\n\nv3.0.0-alpha.x\n\n### Description\n\nTo simplify customization and ensure visual consistency across projects, it would be useful to add a configuration option to define `defaultVariants` globally or for specific component types. These variants could include default size, color, and variant properties for all components or specific ones like buttons, button groups, and form fields. \n\n### Proposal: \n1. Introduce a `defaultVariants` field in the Nuxt configuration to: \n - Define **global variants** (applied to all components). \n - Define **component-specific variants** (e.g., for buttons, forms, etc.). \n\n### Example Implementation: \nIn the Nuxt configuration file: \n```javascript\nexport default defineNuxtConfig({\n ui: {\n defaultVariants: {\n // Global variants\n global: {\n size: 'lg',\n color: 'neutral',\n },\n // Button and ButtonGroup variants\n button: {\n size: 'md',\n color: 'primary',\n variant: 'solid',\n },\n // Form input, select, … variants\n form: {\n size: 'lg',\n color: 'neutral',\n variant: 'outlined',\n },\n },\n },\n});\n``` \n\n### Usage: \nThe defined `defaultVariants` would automatically be applied to all components without the need to explicitly specify these props in templates. Props provided in the template would always take precedence over the ones defined in the configuration. \n\n### Benefits: \n- Reduces repetition in templates. \n- Enhances visual consistency across the project. \n- Flexibility to customize globally or per component type. \n- Easy adoption with prop priority management. \n\n### Expected Impact: \nThis feature would add flexibility while making the integration of `@nuxt/ui` faster and more intuitive by allowing consistent and customized variants to be managed at various levels of the project. \n\nThanks for your continued work on `@nuxt/ui`, which remains an essential tool for building modern and performant interfaces. \n\n### Additional context\n\n_No response_",[3244,3245],{"name":3159,"color":3160},{"name":3162,"color":3163},2934,"Add `defaultVariants` option to define global or component-specific size, variant, and color settings","2025-07-09T12:37:51Z","https://github.com/nuxt/ui/issues/2934",0.7016014,{"description":3252,"labels":3253,"number":3254,"owner":3170,"repository":3255,"state":3209,"title":3256,"updated_at":3257,"url":3258,"score":3259},"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","Inflexible nuxt options override","2023-12-02T00:13:07Z","https://github.com/nuxt/test-utils/issues/270",0.7153628,{"description":3261,"labels":3262,"number":3264,"owner":3170,"repository":3171,"state":3209,"title":3265,"updated_at":3266,"url":3267,"score":3268},"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",[3263],{"name":3181,"color":3182},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,{"description":3270,"labels":3271,"number":3279,"owner":3170,"repository":3171,"state":3209,"title":3280,"updated_at":3281,"url":3282,"score":3283},"### Description\n\n### 🚀 Feature Request\nI’d like to suggest adding a built-in `\u003CDynamicRenderer>` component to Nuxt UI that renders dynamic, nested components based on a configuration object.\n\n### 📋 Motivation\nThis component would be ideal for:\n\n- Form builders\n\n- CMS-driven UIs\n\n- Low-code tools\n\n- Declarative UI rendering\n\nIt simplifies the process of rendering deeply nested structures without hardcoding components in the template.\n\n### 💡 Proposal\nThe DynamicRenderer would accept a config prop that defines:\n\n- The component to render\n\n- Props to bind\n\n- Slot content (including nested component trees)\n\nIt would recursively render components and their slots. Here's an example implementation:\n\n\n#### `DynamicRenderer.vue`\n```vue\n\u003Cscript setup lang=\"ts\">\ndefineProps\u003C{ config: any }>()\n\u003C/script>\n\n\u003Ctemplate>\n \u003Ccomponent :is=\"config.component\" v-bind=\"config\">\n \u003Ctemplate\n v-for=\"(slotContent, slotName) in config.slots\"\n #[slotName]\n >\n \u003Ctemplate v-if=\"typeof slotContent === 'string'\">\n {{ slotContent }}\n \u003C/template>\n\n \u003Ctemplate v-else-if=\"Array.isArray(slotContent)\">\n \u003CDynamicRenderer\n v-for=\"(nested, index) in slotContent\"\n :key=\"index\"\n :config=\"nested\"\n />\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_",[3272,3275,3276,3277,3278],{"name":3273,"color":3274},"feature","A27AF6",{"name":3162,"color":3163},{"name":3220,"color":3221},{"name":3165,"color":3166},{"name":3168,"color":3166},4138,"✨ Feature Request: Add `\u003CDynamicRenderer>` component for config-driven UI rendering","2025-09-03T02:01:06Z","https://github.com/nuxt/ui/issues/4138",0.72745526,["Reactive",3285],{},["Set"],["ShallowReactive",3288],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$f_k1yS0gYdjrfCMdaADhDQDxpuelppV3EQ1UqIcArHyQ":-1},"/nuxt/ui/3382"]