\n```\n\n---\nbut if i set defaultVariants in `app.config` its works:\n```\ndefaultVariants: {\n color: 'neutral',\n button: true\n},\n```\n\n---\nso how do you make it work?",[2867,2870],{"name":2868,"color":2869},"question","d876e3",{"name":2871,"color":2872},"v3","49DCB8",3179,"nuxt","ui","open","Understanding how variants work (custom variants)","2025-01-26T09:27:59Z","https://github.com/nuxt/ui/issues/3179",0.75566435,{"description":2882,"labels":2883,"number":2887,"owner":2874,"repository":2874,"state":2876,"title":2888,"updated_at":2889,"url":2890,"score":2891},"I believe the Nuxt documentation is rich in explanations and examples, thanks to the contributions of many open-source contributors. However, as the documentation rapidly expands, would it be beneficial to maintain a more consistent structure and ordering of sections? This could improve readability for users and make it easier for contributors to edit and navigate the documentation. \n\nCurrently, I’ve noticed some inconsistencies. For example, the function parameters section is labeled **\"Parameters\"** on some pages but **\"Params\"** on others. Additionally, some pages introduce type definitions at the beginning, while others place them at the end. \n\nWould it make sense to standardize these sections, including their order, to create a more structured and cohesive documentation experience? \n\nBelow are some rough ideas I’ve gathered for a possible structure. Of course, not every page may need all of these sections: \n\n- **Usage**: Explains how to use the function or feature, often including basic examples and common use cases. \n- **Type or Type Declarations**: Defines the TypeScript types related to the function or component, helping users understand expected input and output structures. \n- **Parameters**: Lists and describes the function’s input arguments, including their types, default values, and possible options. \n- **Return Values**: Details what the function returns, including any relevant types, structures, or expected behaviors. \n- **Example**: Provides one or more practical usage examples to demonstrate the function in action. \n\nI'm not sure if this would be helpful, so I’d love to hear your thoughts. If there’s anything I haven’t considered, please feel free to let me know. I really appreciate your feedback! 😊\n",[2884],{"name":2885,"color":2886},"documentation","5319e7",30930,"Standardizing section order in Nuxt documentation for better readability","2025-02-11T17:07:23Z","https://github.com/nuxt/nuxt/issues/30930",0.757694,{"description":2893,"labels":2894,"number":2904,"owner":2874,"repository":2874,"state":2876,"title":2905,"updated_at":2906,"url":2907,"score":2908},"We have experimental support in Nuxt 3 for both island components and server-only components (which are implemented using islands) - see https://github.com/nuxt/framework/pull/5689 and https://github.com/nuxt/framework/pull/9972 for initial implementations and https://github.com/nuxt/nuxt/discussions/17956 for initial partial RFC.\r\n\r\nThere are a number of future linked improvements. This issue is to track those and provide some place to document the linking story, purpose and usage of server components within Nuxt.\r\n\r\n## Purpose and usage\r\n\r\nCurrently we are collecting use patterns to ensure that the final API and implementation for server components is useful. But the following are some benefits we are exploring:\r\n\r\n1. security and direct access to server APIs within certain components\r\n2. separate caching strategies for individual chunks of HTML\r\n3. leaner bundle size (keeping some dependencies solely on the server, e.g. syntax highlighting)\r\n4. extensibility\r\n5. rendering individual components within other modules or server routes (e.g. for component previews, OG images, PDF downloads, etc.)\r\n6. ...\r\n\r\nComments and suggestions are very welcome.\r\n\r\n```[tasklist]\r\n### Roadmap\r\n- [x] Allow async components - https://github.com/nuxt/nuxt/issues/18500\r\n- [x] Client-side interactivity - https://github.com/nuxt/nuxt/issues/19765\r\n- [x] remove server component content from payload and prefetch on route transition: https://github.com/nuxt/nuxt/pull/21461\r\n- [x] Hybrid/remote/streaming sources for server components - https://github.com/nuxt/nuxt/issues/12343\r\n- [x] lazy (non-blocking) server components\r\n- [x] interactive components within server components\r\n- [x] deep interactive components within server components\r\n- [x] slot refactor to stabilize the API for other remotes sources such as CMS\r\n- [x] server pages\r\n- [ ] Looking for server-side Performance optimisation opportunity\r\n- [ ] A deep documentation for islands\r\n- [ ] Apply islands features to non SFC components\r\n```",[2895,2898,2901],{"name":2896,"color":2897},"enhancement","8DEF37",{"name":2899,"color":2900},"discussion","538de2",{"name":2902,"color":2903},"🍰 p2-nice-to-have","0E8A16",19772,"server component roadmap","2025-03-17T18:46:11Z","https://github.com/nuxt/nuxt/issues/19772",0.75880826,{"description":2910,"labels":2911,"number":2913,"owner":2874,"repository":2874,"state":2914,"title":2915,"updated_at":2916,"url":2917,"score":2918},"### Describe the feature\n\nHello,\r\n\r\nThe current module author guide, https://nuxt.com/docs/guide/going-further/modules, is great but not very practical or actionable. It answers to some questions but note in depth and rarely say why you should do this or that, when you should use this or that.\r\n\r\nI get the feeling that he's trying not to take sides on the way things are done but it's frustrating when you don't know how to do things.\r\n\r\nI would love to have something with more rules, more strict, with conventions.\r\n\r\nFor examples, when should I use the `prepare` , how to log (and which logger should I use), to tell to users to take care of bundle size and maybe more things to make author module life easier.\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).",[2912],{"name":2885,"color":2886},25603,"closed","Improve Nuxt Module Author Guide","2025-03-24T22:23:22Z","https://github.com/nuxt/nuxt/issues/25603",0.7453155,{"description":2920,"labels":2921,"number":2927,"owner":2874,"repository":2874,"state":2914,"title":2928,"updated_at":2929,"url":2930,"score":2931},"Initially, we started documenting usage explanations and examples to the same directory structure in the docs. \r\n\r\nWhile this is a nice feature of docs to navigate through and visually see what each directory of file does, we probably could have better placement for usage of features and concepts and cross linking to detailed parts when applicable. Pages like [features API](https://v3.nuxtjs.org/guide/features/plugins) are currently empty.\r\n\r\nI think we could split docs like this per feature:\r\n- Feature or Concept explanation with usage examples\r\n - Link to API\r\n - Link to directory-structure \r\n - Link to examples\r\n- API page for signature and detailed argument explanation\r\n - Link to feature/concept\r\n- Directory structure page that explains **how the files are auto-scanned**\r\n - Link to feature/concept\r\n- Examples\r\n - Link to feature/concept\r\n\r\n\r\nSections to split:\r\n\r\n- [ ] Plugins\r\n - https://v3.nuxtjs.org/guide/directory-structure/plugins => [features/plugin](https://v3.nuxtjs.org/guide/features/plugins)\r\n- [ ] Components\r\n - https://v3.nuxtjs.org/guide/directory-structure/components => [concepts/components?]\r\n- [ ] Layouts\r\n - https://v3.nuxtjs.org/guide/directory-structure/layouts => [features/layouts?]\r\n- [ ] Middleware\r\n - https://v3.nuxtjs.org/guide/directory-structure/middleware => [features/routing?]\r\n- [ ] Pages\r\n - https://v3.nuxtjs.org/guide/directory-structure/pages => [features/routing?]\r\n",[2922,2923,2924],{"name":2885,"color":2886},{"name":2899,"color":2900},{"name":2925,"color":2926},"3.x","29bc7f",14663,"[docs] Split usage from directory structure","2023-01-19T17:39:02Z","https://github.com/nuxt/nuxt/issues/14663",0.7464415,{"description":2933,"labels":2934,"number":2937,"owner":2874,"repository":2874,"state":2914,"title":2938,"updated_at":2939,"url":2940,"score":2941},"**Summary (generated)**:\n\nHere is a brief summary in English:\n\nThe feature mentions the usage of package managers, including pnpm and bun, as alternatives to npm and npx in certain places. The author is willing to help implement the feature and confirms they have read the contribution guide and checked existing discussions and issues on the GitHub repository.\n\n\u003Chr>\n\n### Describe the feature\n\nIn some places, pnpm and bun are also used, whereas in some places it is just npm/npx.\n\n### Additional information\n\n- [X] 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).",[2935,2936],{"name":2885,"color":2886},{"name":2902,"color":2903},27790,"Documentation Improvment - All package managers throughout docs","2025-03-24T22:25:53Z","https://github.com/nuxt/nuxt/issues/27790",0.7499705,{"labels":2943,"number":2945,"owner":2874,"repository":2874,"state":2914,"title":2946,"updated_at":2947,"url":2948,"score":2949},[2944],{"name":2885,"color":2886},13653,"Documentation progress","2025-02-22T22:32:21Z","https://github.com/nuxt/nuxt/issues/13653",0.75826967,{"labels":2951,"number":2954,"owner":2874,"repository":2874,"state":2914,"title":2955,"updated_at":2956,"url":2957,"score":2958},[2952,2953],{"name":2885,"color":2886},{"name":2925,"color":2926},11912,"Add readme to examples","2023-01-19T15:49:20Z","https://github.com/nuxt/nuxt/issues/11912",0.758552,{"description":2960,"labels":2961,"number":2970,"owner":2874,"repository":2874,"state":2914,"title":2971,"updated_at":2972,"url":2973,"score":2974},"### Describe the feature\n\nCurrently, the pages module has a very limited configuration option. It can be enabled/disabled and we can change the dir name. I would like to improve this to bring it on par with the configuration available for components and composables.\r\n\r\nExample: in the following directory structure I want to automatically load only Vue files (could be customizable with a glob pattern).\r\n```\r\npages\r\n somePage\r\n index.vue\r\n pageSpecificHelper.ts\r\n pageAsyncData.ts\r\n generated\r\n GQLGeneratedTypes.ts\r\n```\r\nCurrently, I have a couple of workarounds like adding `-` prefixes, or `ignore` config (though it affects all auto-imports).\r\n\r\nI would be happy to work on this myself. The idea I have would be to allow `pages` config to be an object with an option for `pattern` (or use the existing `ScanDir` interface for more configuration) and then change [this line in resolvePagesRoutes](https://github.com/nuxt/framework/blob/main/packages/nuxt/src/pages/utils.ts#L38) with fallback to the current pattern.\r\n\r\n---\r\n\r\nMore broadly speaking, I imagine that a more consistent and granular configuration of auto-imports would benefit many bigger projects. But this would be a bigger change affecting components, composables, plugins, and pages configuration. \n\n### Additional information\n\n- [X] 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).",[2962,2963,2964,2967],{"name":2896,"color":2897},{"name":2925,"color":2926},{"name":2965,"color":2966},"workaround available","11376d",{"name":2968,"color":2969},"❌ won't do","705B27",12333,"Improved pages module configuration","2024-11-28T05:07:59Z","https://github.com/nuxt/nuxt/issues/12333",0.7592565,{"description":2976,"labels":2977,"number":2984,"owner":2874,"repository":2874,"state":2914,"title":2985,"updated_at":2986,"url":2987,"score":2988},"### Describe the feature\r\n\r\nThe current directory structure can be overwhelming for a large project. Considering that the server directory is already pretty much separate from the rest of the app, It'd be nice if we could separate those concerns at the directory level.\r\nMy proposal is a new `clientDir` option similar to `srcDir`.\r\n\r\nExample if `clientDir` set to `client/`:\r\n```\r\n|-- client\r\n |-- assets\r\n |-- components\r\n |-- composables\r\n |-- layouts\r\n |-- middleware\r\n |-- pages\r\n |-- public\r\n|-- plugins\r\n|-- server\r\n |-- api\r\n |-- middleware\r\n|-- nuxt.config.ts\r\n|-- package.json\r\n```\r\n\r\nthe current workaround is:\r\n```typescript\r\nexport default defineNuxtConfig({\r\n dir: {\r\n layouts: 'client/layouts',\r\n middleware: 'client/middleware',\r\n public: 'client/public',\r\n pages: 'client/pages',\r\n },\r\n imports: {\r\n dirs: ['client/composables'],\r\n },\r\n components: {\r\n dirs: ['client/components'],\r\n },\r\n tailwindcss: { cssPath: './client/assets/css/tailwind.css' }, // Module specific changes\r\n});\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- [ ] Could this feature be implemented as a module?\r\n\r\n### Final checks\r\n\r\n- [X] Read the [contribution guide](https://v3.nuxtjs.org/community/contribution).\r\n- [X] Check existing [discussions](https://github.com/nuxt/framework/discussions) and [issues](https://github.com/nuxt/framework/issues).",[2978,2979,2982,2983],{"name":2896,"color":2897},{"name":2980,"color":2981},"good first issue","fbca04",{"name":2925,"color":2926},{"name":2902,"color":2903},14944,"An option for having separate server and client directories","2023-01-19T17:42:56Z","https://github.com/nuxt/nuxt/issues/14944",0.75979656,["Reactive",2990],{},["Set"],["ShallowReactive",2993],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$fwvIb50H6raVMAVeWR4JdXWMd18zbzcu-EyPtz3B6N54":-1},"/nuxt/ui/2729"]