` 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_",[3020,3023,3026],{"name":3021,"color":3022},"enhancement","a2eeef",{"name":3024,"color":3025},"v3","49DCB8",{"name":3027,"color":3028},"triage","ffffff",4263,"nuxt","ui","closed","provide zod schemas for nuxt content collections","2025-05-30T20:56:17Z","https://github.com/nuxt/ui/issues/4263",0.6144646,{"description":3038,"labels":3039,"number":3048,"owner":3030,"repository":3030,"state":3032,"title":3049,"updated_at":3050,"url":3051,"score":3052},"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",[3040,3042,3045],{"name":3021,"color":3041},"8DEF37",{"name":3043,"color":3044},"discussion","538de2",{"name":3046,"color":3047},"3.x","29bc7f",15592,"Custom config schema","2023-04-07T01:47:49Z","https://github.com/nuxt/nuxt/issues/15592",0.67275494,{"description":3054,"labels":3055,"number":3057,"owner":3030,"repository":3031,"state":3032,"title":3058,"updated_at":3059,"url":3060,"score":3061},"### 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.",[3056],{"name":3021,"color":3022},2891,"Export of every components","2025-01-13T16:32:50Z","https://github.com/nuxt/ui/issues/2891",0.70475566,{"labels":3063,"number":3066,"owner":3030,"repository":3030,"state":3032,"title":3067,"updated_at":3068,"url":3069,"score":3070},[3064,3065],{"name":3021,"color":3041},{"name":3046,"color":3047},12790,"Support `global: false` for components","2023-01-19T16:35:12Z","https://github.com/nuxt/nuxt/issues/12790",0.7072851,{"description":3072,"labels":3073,"number":3077,"owner":3030,"repository":3030,"state":3032,"title":3078,"updated_at":3079,"url":3080,"score":3081},"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>",[3074],{"name":3075,"color":3076},"2.x","d4c5f9",421,"Define global components","2023-01-18T22:17:23Z","https://github.com/nuxt/nuxt/issues/421",0.70772505,{"description":3083,"labels":3084,"number":3092,"owner":3030,"repository":3031,"state":3032,"title":3093,"updated_at":3094,"url":3095,"score":3096},"### 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```",[3085,3088,3089],{"name":3086,"color":3087},"question","d876e3",{"name":3024,"color":3025},{"name":3090,"color":3091},"stale","ededed",3679,"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.7086086,{"description":3098,"labels":3099,"number":3104,"owner":3030,"repository":3030,"state":3032,"title":3105,"updated_at":3106,"url":3107,"score":3108},"### 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_",[3100,3101],{"name":3046,"color":3047},{"name":3102,"color":3103},"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,{"description":3110,"labels":3111,"number":3114,"owner":3030,"repository":3031,"state":3032,"title":3024,"updated_at":3115,"url":3116,"score":3117},"The development is ongoing on the default branch of this repository: https://github.com/nuxt/ui.\n\n---\n\nA lot has changed since `@nuxt/ui` was made open-source (May 2023), so the plan here is to rewrite every component from scratch alongside their config.\n\nI'll post regular updates on this issue and on https://twitter.com/benjamincanac.\n\n## Documentation\n\nhttps://ui3.nuxt.dev\n\n## Roadmap (Nov 20, 2024)\n\n- [x] Finish the migration to `reka-ui@alpha` on `@nuxt/ui` & `@nuxt/ui-pro` #2448\n- [x] Write the docs for implemented `@nuxt/ui-pro` components\n- [x] Finish `@nuxt/ui-pro` components\n- [x] Make Nuxt UI Pro v3 work with Vue like Nuxt UI https://github.com/nuxt/ui-pro/pull/742\n- [ ] Implement new components in `@nuxt/ui` like\n - [x] `Calendar` #2618\n - [ ] `InputDate` #2524\n - [x] `Tree` #3180\n - [x] `Stepper` #2733\n- [x] Migrate all the Nuxt UI Pro templates\n - [x] Starter\n - [x] Landing\n - [x] Docs\n - [x] SaaS https://github.com/nuxt-ui-pro/saas/pull/86\n - [x] Dashboard https://github.com/nuxt-ui-pro/dashboard/pull/86\n- [ ] Build the Nuxt UI docs marketing pages\n - [x] Landing\n - [x] Figma\n - [x] Pro -> Landing\n - [x] Pro -> Pricing\n - [x] Pro -> Templates\n - [x] Pro -> Activate\n - [ ] Releases\n- [x] Write migration guide https://ui3.nuxt.dev/getting-started/migration\n- [x] Release `@nuxt/ui` & `@nuxt/ui-pro` officially once `tailwindcss` and `reka-ui` are released\n- [x] Migrate all the Nuxt apps (nuxt.com, image.nuxt.com, eslint.nuxt.com, devtools.nuxt.com, fonts.nuxt.com, hub.nuxt.com, nuxt.studio, etc.)\n- [ ] Implement new `@nuxt/ui` & `@nuxt/ui-pro` components\n- [ ] Create new templates like Changelog, Portfolio, etc. \n\n## Breaking Changes\n\nThe biggest change is the switch to `tailwind-variants`, this will cause lots of breaking changes if you've used the `ui` prop or `app.config.ts` to override the config. I apologize in advance for this but I strongly believe this will be beneficial and will bring consistency across all components.\n\n> At the beginning the config was split in many keys for the same div to give more flexibility, but since then we introduced `tailwind-merge` which now allows us to group those keys together, this is a good opportunity to clean the whole thing. \n\nThe config will now have a `slots` amongst other keys that will specifically target dom nodes. The `ui` prop will only allow you to target those slots.\n\nThese changes alongside the refactor of all components will also improve the types, the `app.config.ts` and `ui` props are now perfectly typed, as well as all components `props`, `slots`, `emits` and `expose`.\n\n> Feel free to comment on this if you have any ideas for the next major.\n\n```[tasklist]\n### Components\n- [x] Accordion\n- [x] Alert\n- [x] Avatar\n- [x] AvatarGroup\n- [x] Badge\n- [x] Breadcrumb\n- [x] Button\n- [x] ButtonGroup\n- [x] Card\n- [x] Carousel\n- [x] Checkbox\n- [x] Chip\n- [x] Collapsible\n- [x] CommandPalette\n- [x] Container\n- [x] ContextMenu\n- [x] Drawer\n- [x] DropdownMenu (Dropdown)\n- [x] Form\n- [x] FormField (FormGroup)\n- [x] Icon\n- [x] Input\n- [x] InputMenu\n- [x] Kbd\n- [x] Link\n- [x] Modal\n- [x] NavigationMenu (HorizontalNavigation/VerticalNavigation)\n- [x] Pagination\n- [x] Popover\n- [x] Progress\n- [x] Provider\n- [x] RadioGroup\n- [x] Select\n- [x] SelectMenu\n- [x] Separator (Divider)\n- [x] Skeleton\n- [x] Slideover\n- [x] Slider (Range)\n- [x] Table\n- [x] Tabs\n- [x] Textarea\n- [x] Toast (Notification)\n- [x] Switch (Toggle)\n- [x] Tooltip\n```\n",[3112],{"name":3113,"color":3025},"release",1289,"2025-07-17T12:55:11Z","https://github.com/nuxt/ui/issues/1289",0.7129574,{"labels":3119,"number":3122,"owner":3030,"repository":3030,"state":3032,"title":3123,"updated_at":3124,"url":3125,"score":3126},[3120,3121],{"name":3021,"color":3041},{"name":3046,"color":3047},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":3128,"labels":3129,"number":3132,"owner":3030,"repository":3030,"state":3032,"title":3133,"updated_at":3134,"url":3135,"score":3136},"- [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)",[3130,3131],{"name":3043,"color":3044},{"name":3046,"color":3047},11026,"Components Discovery","2023-01-19T14:46:30Z","https://github.com/nuxt/nuxt/issues/11026",0.7145133,["Reactive",3138],{},["Set"],["ShallowReactive",3141],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$flgGUetConR7uOT2QobccDk5Wp0A_Hp95mrriE1XsxQo":-1},"/nuxt/ui/4161"]