\n\n- [ ] **`UInputEditor`**\nSince Reka UI lacks a native editor component, I recommend integrating a third-party solution like [Quill](https://quilljs.com) or [TipTap](https://tiptap.dev) (which already offers Nuxt/Vue support). Although previously dismissed by the author, this feature remains highly requested by the community. \u003Cbr>\u003Cimg width=\"1009\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/4862e9e8-4769-4bd3-a40e-bc89cea5d1a1\" />\n_Related: #2698, #1889, #791_\n\n- [ ] **`UInputTime`**\nImplement the `TimeField` component from Reka UI, this component could support single and range-based time selection.\n_Related: #3089, #3969, #4634_ \u003Cbr>\u003Cimg width=\"175\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/7e338f95-eae3-4ef8-81cc-b3db28553b4e\" />\n\n- [ ] **`UInputDate`**\nImplementation of Reka UI’s `DatePicker` and `DateRangePicker`. \u003Cbr>\u003Cimg width=\"608\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/fcae5c2d-50ed-4b8b-ac89-b3272626fd48\" />\n_Related: #2524, #2873_\n\n- [ ] **`UInputDateTime`**\nA hybrid component combining `UInputDate` and `UInputTime` for scenarios requiring both date and time inputs. \u003Cbr>\u003Cimg width=\"303\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/2372467f-ca86-44a0-9667-6dc3ffa43247\" />\n\n- [ ] **`UInputMonth`**\nIdeal for cases where users need to select a combination of month and year. \u003Cbr>\u003Cimg width=\"249\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/7ee72087-0d58-47ca-b0f7-b5c239148d91\" />\n\n- [ ] **`UInputYear`**\nA simpler component for year-only selection. \u003Cbr>\u003Cimg width=\"247\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/a841c974-43b7-42a1-ac3c-7fb42e85fafc\" />\n\n- [ ] **`UInputMask`**\nMasked inputs are indispensable for formatting fields like postal codes or national IDs. I suggest leveraging [Vue The Mask](https://github.com/vuejs-tips/vue-the-mask) for implementation. \u003Cbr>\u003Cimg width=\"316\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/b2a3150f-a29e-40ad-96c1-32a63b3bd9ac\" />\n_Related: #1303, #510_\n\n- [ ] **`UInputPhone`**\nA phone input with internationalization support, much like `LocaleSelect` (which already displays flags and country names). The [libphonenumber-js](https://www.npmjs.com/package/libphonenumber-js) library could serve as the foundation. \u003Cbr>\u003Cimg width=\"312\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/893a1bf3-130c-49da-b41e-8ebf468569a4\" />\n_Related: #2815_\n\n## Updates to Existing Components\n\n- [ ] **`UPinInput → UInputPin`**\nRename the existing `UPinInput` component to align with the naming convention used across other input components.\n\n- [ ] **`UInput / UTextarea`**\nAdd a native character counter via a `counter` property, configurable using the `min` and/or `max` attributes. Currently, there is an [example](https://ui3.nuxt.dev/components/input#with-character-limit) for this functionality, but a native implementation would improve the developer experience.\n\n### Additional context\n\n_No response_",[3156,3159],{"name":3157,"color":3158},"feature","A27AF6",{"name":3160,"color":3161},"v3","49DCB8",3094,"[RFP] The Inputs Update","2025-07-31T02:45:34Z","https://github.com/nuxt/ui/issues/3094",0.71614814,{"description":3168,"labels":3169,"number":3184,"owner":3146,"repository":3146,"state":3148,"title":3185,"updated_at":3186,"url":3187,"score":3188},"### Describe the feature\r\n\r\nEdit : Form actions have been released as a Nuxt module 🎉 Please try it and leave feedback.\r\n\r\n- Docs : https://form-actions-nuxt.pages.dev/\r\n- Module : https://nuxt.com/modules/form-actions\r\n- GitHub : https://github.com/Hebilicious/form-actions-nuxt\r\n\r\n--- \r\n\r\nProgressively enhanced patterns relies on using native forms to make it easier to have apps that works without JavaScript. This can work well with Nuxt Server components too, as it could allow client-server communication with 0client side javascript. While this is not desirable in all scenarios, and having this as the default to do everything is very opinionated, it would be nice to support these patterns at the framework level : \r\n\r\nMultiple frameworks already support this pattern (Remix, SvelteKit, SolidStart ...), and Next is adding it :\r\n\r\n\r\nFor Nuxt, it's (almost) possible already to implement this patterns by doing something like this (in /server/api/pespa.ts) : \r\n\r\n```ts\r\nimport { EventHandler, H3Event } from \"h3\"\r\n\r\ntype Actions = {\r\n [key: string]: EventHandler\r\n}\r\n\r\nconst defineFormActions = (actions: Actions) => async (event: H3Event) => {\r\n const action = Object.keys(getQuery(event))[0] ?? \"default\"\r\n const method = getMethod(event)\r\n if (method === \"POST\") return defineEventHandler(actions[action])(event)\r\n}\r\n\r\nexport default defineFormActions({\r\n default: async (event) => {\r\n const form = await readMultipartFormData(event)\r\n const body = await readBody(event)\r\n const contentType = getHeader(event, \"content-type\")\r\n console.log({ form, body, contentType })\r\n return sendRedirect(event, \"/pespa\")\r\n },\r\n logout: async (event) => {\r\n const form = await readMultipartFormData(event)\r\n const body = await readBody(event)\r\n const contentType = getHeader(event, \"content-type\")\r\n console.log({ form, body, contentType })\r\n return sendRedirect(event, \"/pespa\")\r\n }\r\n})\r\n```\r\n\r\nThen creating a page at /pespa ...\r\n```vue\r\n\u003Ctemplate>\r\n \u003Cform method=\"POST\" action=\"api/pespa\">\r\n \u003Clabel>\r\n Email\r\n \u003Cinput name=\"email\" type=\"email\" value=\"john@doe.com\" />\r\n \u003C/label>\r\n \u003Clabel>\r\n Password\r\n \u003Cinput name=\"password\" type=\"password\" value=\"password\" />\r\n \u003C/label>\r\n \u003Cbutton>Log in\u003C/button>\r\n \u003C/form>\r\n \u003Cform method=\"POST\" action=\"api/pespa?logout\">\r\n \u003Cbutton>Log Out\u003C/button>\r\n \u003C/form>\r\n\u003C/template>\r\n```\r\n\r\nHowever here we have to use \"/api\" for the action attribute, and the DX isn't the best for multiple reasons.\r\n\r\nIt would be nice to have a `/actions` directory (in `/server` for nuxt) so that we can define form actions more easily. \r\n(This probably needs a discussion/RFC somewhere so that the Nuxt/Nitro/H3 side can be updated together, let me know if I should repost this somewhere else)\r\n\r\nFor the nitro syntax, the `defineFormAction` I proposed above could be integrated in nitro, as a replacement for defineEventHandler. \r\n\r\nI'm not sure if manually redirecting in the action handler is the best way to do things, perhaps what would need to happen for Nuxt specifically is to generate POST only handlers for these form actions, while these GET methods to the same URL are handled by the corresponding route or nuxt page.\r\n\r\nIf I'm not mistaken, for Nuxt we also need a way to easily pass data back and forth, perhaps the existing ways can be used, but a new composable feels appropriate. \r\n\r\nThere's also a need for something similar to sveltekit [use:enhance / applyAction](https://kit.svelte.dev/docs/form-actions#progressive-enhancement) to make it easier to progressively enhance forms (altough, e.preventDefault() could be enough, the DX is a little barebones)\r\n\r\nHaving something like `getNativeRequest` from H3 would be really useful too: \r\n\r\n```ts\r\neventHandler(event => {\r\nconst request = getNativeRequest(event)\r\nconst data = request.formData()\r\n//do stuff\r\n})\r\n```\r\n*This might need some change in @vue/core, see [React here.](https://github.com/facebook/react/pull/26749)*\r\n\r\n### Proposed API :\r\n\r\nI'm suggesting an API here to illustrate what we could do. \r\n\r\n`pages/signIn.vue`\r\n```vue\r\n\u003Cscript setup> \r\nconst { enhance } = useEnhance(({form, data, action, cancel, submitter }) => {\r\n // Using SvelteKit API to illustrate, but the Nuxt one could/should be different ...\r\n // `form` is the `\u003Cform>` element;`data` is its `FormData` object\r\n // `action` is the URL to which the form is posted;v`cancel()` will prevent the submission\r\n // `submitter` is the `HTMLElement` that caused the form to be submitted\r\n return async ({ result, update }) => {\r\n // `result` is returned by the matching defineFormAction ....\r\n // `update` is a function which triggers the logic that would be triggered if this callback wasn't set\r\n };\r\n})\r\n\r\n// Alternatively something like this, which I personally prefer...\r\nconst { result, loading, error, enhance } = useAction(\"signIn\", (actionSettings) => {\r\n// actions settings could contain form, data, action, cancel ... like in useEnhance\r\n}) \r\n//Can use result/loading/error etc in the template for conditional rendering\r\n\u003C/script>\r\n\u003Ctemplate>\r\n \u003Cform method=\"post\" action=\"signIn\" v-enhance=\"enhance\">\r\n \u003Clabel>\r\n Email\r\n \u003Cinput name=\"email\" type=\"email\" value=\"john@doe.com\" />\r\n \u003C/label>\r\n \u003Clabel>\r\n Password\r\n \u003Cinput name=\"password\" type=\"password\" value=\"password\" />\r\n \u003C/label>\r\n \u003Cbutton>Log in\u003C/button>\r\n \u003C/form>\r\n\u003C/template>\r\n```\r\n\r\n`server/signIn.vue`\r\n```ts\r\nexport defineFormAction((event) => {\r\n const request = getNativeRequest(event)\r\n const data = request.formData()\r\n \r\n// signin the User\r\n// Not that we should have a way to return something that works \r\n// well with progressive enhancement to the client,\r\n//Like a JSON payload that can contain data and \"metadata\" (errors, redirects )\r\n// so they can be applied smoothly in CSR. \r\n// A `respondWithFormAction` helper could be added too.\r\nconst result = `This was sent ${JSON.stringify(data)}`\r\nreturn actionResponse(event, { result } )\r\n})\r\n```\r\n\r\nTo recap here : \r\n\r\n- New vue directive for nuxt, `v-enhance` to use on forms to enhance them\r\n- New event handler for Nitro or H3, `defineFormAction`. Could accept a function or an object of functions\r\n- New server directory for Nitro `/server/actions` to define server actions.\r\n- New helpers for H3 `getNativeRequest()` and `actionResponse()` to simplify the action workflow\r\n- New feature for Nuxt, `useAction` or `useEnhance`, to work with actionResponse and v-enhance. \r\n\r\nOverall I feel like this API is respectful of the standard web semantics, and feels vue-ish. Feel free to suggest any improvements for it.\r\n\r\n### Reference from other frameworks : \r\n- [Svelte Form actions](https://kit.svelte.dev/docs/form-actions), [Discussion for semantic form actions](https://github.com/sveltejs/kit/discussions/5875)\r\n- [Solid Start actions](https://start.solidjs.com/core-concepts/actions)\r\n- [Remix Actions](https://remix.run/docs/en/main/route/action)\r\n- [Kent PESPA article](https://www.epicweb.dev/the-webs-next-transition)\r\n- [Next.js Server Actions](https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions)\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).",[3170,3172,3175,3178,3181],{"name":3140,"color":3171},"8DEF37",{"name":3173,"color":3174},"discussion","538de2",{"name":3176,"color":3177},"dx","C39D69",{"name":3179,"color":3180},"nitro","bfd4f2",{"name":3182,"color":3183},"🍰 p2-nice-to-have","0E8A16",20649,"Form actions for progressive enhancement","2024-06-30T11:08:54Z","https://github.com/nuxt/nuxt/issues/20649",0.7227241,{"description":3190,"labels":3191,"number":3194,"owner":3146,"repository":3146,"state":3148,"title":3195,"updated_at":3196,"url":3197,"score":3198},"### Describe the feature\n\nHey I am currently moving a big project from standard vue3 to nuxt, and have to rewrite most of my options api code to composition api..\r\n\r\nThe issue mostly is that some features are not there in composition api and when one is missing i can't \"link\" it to options api and then i got to go down the rabbit hole of changing my code to use composition api although it's already completely valid options api code.\r\n\r\nFor real, props, it is an awesome framework and it's very impressive etc.\r\n\r\nBUT.... in my opinion, it is kind of weird that it does not fully support vue (from my pov) as i do have to use so much \"special\" vue code instead of easily porting my app.\r\n\r\nI am still continuing to use nuxt for now but if you were able to make the transition a bit easier, i think a lot of people would use nuxt instead of plain old vue 3.\r\n\r\nI am willing to help with the adoption by saying what needs to happen (for a project like mine) to be easily portable to nuxt, if that is helpful.\r\n\r\nLmk what u think :) \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).",[3192,3193],{"name":3140,"color":3171},{"name":3182,"color":3183},21670,"Missing Support (Or documentation of) Options API with Nuxt","2024-06-30T11:08:29Z","https://github.com/nuxt/nuxt/issues/21670",0.72926223,{"description":3200,"labels":3201,"number":3205,"owner":3146,"repository":3146,"state":3148,"title":3206,"updated_at":3207,"url":3208,"score":3209},"### Describe the feature\n\nHi Nuxt team and Nuxt users!\nI have been working with Nuxt about a year and this is a wonderful fullstack tool for building web applications of any size: from small project, to big custom frameworks built on top of Nuxt.\n\nDespite the fact that Nuxt has excellent documentation, there is a strong need for a set of schemas that clearly show Nuxt as a holistic “ecosystem” of processes and contexts.\n\nLack of schemas and extereme Nuxt flexibility (you can literally hook anywhere) is cauisng confusions and leads to making things \"the hard\" and unoptimal way intead of easy and \"right\" way!\n\nThat's why I decided to sketch out this general outline of how Nuxt works:\n\n\n\n\u003Cdetails>\u003Csummary>Light version\u003C/summary>\n\u003Cp>\n\n\n\n\u003C/p>\n\u003C/details> \n\nThis is still work in progress and you can easily change this schema with [Excalidraw](https://excalidraw.com/) app. You just need to import `.excalidraw` project from the arhive:\n\n[nuxt-scheme.zip](https://github.com/user-attachments/files/21799793/nuxt-scheme.zip)\n\nI think these schemas can be placed at a new Guide page in Nuxt Docs with name \"Nuxt Overview\" or \"Nuxt Schema\". It is also possible to make separate lifecycle schemas for each context individually (module context lifecycle, nitro context lifecycle, nuxt app/vue app lifecycle). So the learner understands the general Nuxt structure first, and after that can dig into detaled context schema he wished to augment.\n\nThe other way is to add them to already existing [\"Nuxt Lifecycle\"](https://nuxt.com/docs/4.x/guide/concepts/nuxt-lifecycle) docs page.\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).",[3202],{"name":3203,"color":3204},"pending triage","E99695",32973,"The Nuxt Schema","2025-08-15T17:17:44Z","https://github.com/nuxt/nuxt/issues/32973",0.7330073,{"description":3211,"labels":3212,"number":3215,"owner":3146,"repository":3147,"state":3216,"title":3217,"updated_at":3218,"url":3219,"score":3220},"### Description\n\n🙏 First of all, thank you to the Nuxt UI team for your outstanding contributions!\n\nNuxt UI has greatly improved the developer experience for building modern Nuxt applications.\n\n---\n\nDescription\n\nCurrently, nuxt/ui provides a powerful set of UI components and form elements, but it lacks a built-in dynamic schema-form system. In many enterprise applications, we spend a lot of repetitive time writing similar form templates and CRUD logic.\n\nI propose adding a \u003Cschema-form> component, similar to [Ant Design ProComponents Schema Form](https://procomponents.ant.design/en-US/components/schema-form), to help developers quickly build dynamic forms with minimal boilerplate.\n\nMotivation\n\t•\tReduce repetitive code for standard CRUD forms.\n\t•\tCentralize form configuration into JSON schema.\n\t•\tAutomatically handle form rendering, validation, and API requests.\n\t•\tSimplify maintenance and improve developer productivity for admin panels and back-office tools.\n\n---\nProposed API\n\nA possible schema-form component interface could be:\n\n```vue\n\u003CSchemaForm\n :schema=\"{\n title: 'User Info',\n mode: 'create', // or 'update'\n api: {\n detail: '/api/user/detail',\n create: '/api/user/create',\n update: '/api/user/update'\n },\n fields: [\n { label: 'Username', name: 'username', component: 'input', rules: [{ required: true }] },\n { label: 'Email', name: 'email', component: 'input' },\n { label: 'Role', name: 'role', component: 'select', options: [\n { label: 'Admin', value: 'admin' },\n { label: 'User', value: 'user' }\n ]}\n ],\n initialValues: { role: 'user' }\n }\"\n @submit-success=\"onSubmit\"\n/>\n```\n---\nFeatures\n\t•\t✅ Schema-driven form rendering (fields, labels, validation, components)\n\t•\t✅ Auto-fetch detail API for edit mode\n\t•\t✅ Built-in submit to create/update APIs\n\t•\t✅ Support for u-input, u-select, u-date-picker, and custom components\n\t•\t✅ Works seamlessly with Nuxt UI design system\n\n---\n\nBenefits\n\t•\tSignificant reduction in repetitive CRUD form code\n\t•\tAligns with enterprise admin panel requirements\n\t•\tMatches developer experience from frameworks like Ant Design ProComponents\n\t•\tMakes Nuxt UI more competitive for dashboard/admin scenarios\n\n---\n\nAlternatives\n\nRight now, developers must:\n\t•\tManually write each form template (using u-form, u-form-item, etc.)\n\t•\tHandle API fetching/submission manually with useFetch\n\t•\tDuplicate similar code across multiple CRUD pages\n\n---\n\nReferences\n\t•\tAnt Design ProComponents Schema Form: https://procomponents.ant.design/en-US/components/schema-form\n\n\n### Additional context\n\n_No response_",[3213,3214],{"name":3140,"color":3141},{"name":3143,"color":3144},4653,"closed","[Feature Request] Add dynamic schema-form similar to Ant Design ProComponents Schema Form for reducing CRUD workload","2025-08-07T17:19:54Z","https://github.com/nuxt/ui/issues/4653",0.7091445,{"description":3222,"labels":3223,"number":3226,"owner":3146,"repository":3147,"state":3216,"title":3160,"updated_at":3227,"url":3228,"score":3229},"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",[3224],{"name":3225,"color":3161},"release",1289,"2025-07-17T12:55:11Z","https://github.com/nuxt/ui/issues/1289",0.71244186,{"description":3231,"labels":3232,"number":3240,"owner":3146,"repository":3146,"state":3216,"title":3241,"updated_at":3242,"url":3243,"score":3244},"### Environment\n\n- Operating System: Linux\r\n- Node Version: v20.10.0\r\n- Nuxt Version: 3.13.2\r\n- CLI Version: 3.13.2\r\n- Nitro Version: 2.9.7\r\n- Package Manager: npm@10.8.3\r\n- Builder: -\r\n- User Config: ssr, css, app, build, modules, nitro, runtimeConfig, serverHandlers, vite, devtools, postcss, compatibilityDate\r\n- Runtime Modules: @pinia/nuxt@0.5.4, @nuxt/eslint@0.5.7\r\n- Build Modules: -\n\n### Reproduction\n\nThe private Vue library:\r\n- works fine when used in a Vue SPA application, e.g. [https://topoeditor.com](https://topoeditor.com)\r\n- works fine when used as a web component in a non Vue application, e.g. https://climbers-club.co.uk/climbing/submission\r\n- no longer works when used in a Nuxt application (non-public) with SSR set as false.\n\n### Describe the bug\n\nThe component loaded from the library works the first time the component is mounted, but on remounting the component, the refs and computed refs within composables in the library do not update correctly resulting in undesirable behaviour.\r\n\r\nThis may be intended Nuxt behaviour (as Nuxt does not support refs in composables for SSR), but making Nuxt incompatible with client-side Vue libraries is surely undesirable (and ultimately will result in my migrating away from Nuxt).\n\n### Additional context\n\nThe TopoEditor library has:\r\n ~ 30 composables containing ~100 refs and similar number of computed refs\r\n ~ 30 components which use values from the composables (saves complex web of props)\n\n### Logs\n\n_No response_",[3233,3234,3237],{"name":3203,"color":3204},{"name":3235,"color":3236},"needs reproduction","FBCA04",{"name":3238,"color":3239},"possible regression","B90A42",29161,"Recent changes cause issues with client side Vue libraries using refs in composables","2024-11-17T21:43:51Z","https://github.com/nuxt/nuxt/issues/29161",0.72751766,{"description":3246,"labels":3247,"number":3254,"owner":3146,"repository":3146,"state":3216,"title":3255,"updated_at":3256,"url":3257,"score":3258},"### Describe the feature\n\nAccording to [this](https://nuxt.com/docs/guide/directory-structure/components#library-authors) you can specify folders from npm packages in the nuxt config (or its hooks) for component auto-scanning. What I dislike about how this works currently is that it seems to scan the source code of that package (.vue files) not the build output.\r\n\r\nThe .vue files of a third party NPM package might rely on custom bundler settings like custom path aliases or maybe custom loaders/plugins for handling imports to files that nuxt won't know how to handle. I also dislike the idea of importing another package's source code, not the build output, cause you can never know what kind of transformations the library author expects to happen during the build making the result actually different from what the source code says.\r\n\r\nAdditionally - this way of importing components is incompatible with non-nuxt applications. A standard Vue application will still need to rely on a standard ESM/CJS module to import the third party components, cause it doesn't have nuxt's vue file scanning mechanism. So you'd need to maintain 2 ways of consuming your package.\r\n\r\n**The solution:** It would make a lot more sense to allow specifying build outputs - the resulting `./dist/library.mjs` file which will have all of the Vue components build into plain JavaScript. Then Nuxt could scan that module for all of the components that are exported and use them that way. Outputting components into an ESM/CJS file is how most component library packages are built, so this would also be more idiomatic in the ecosystem.\n\n### Additional information\n\n- [X] Would you be willing to help implement this feature?\n- [X] 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).",[3248,3249,3250,3253],{"name":3140,"color":3171},{"name":3173,"color":3174},{"name":3251,"color":3252},"3.x","29bc7f",{"name":3182,"color":3183},20799,"Support external library build output scanning for components","2023-06-05T10:25:45Z","https://github.com/nuxt/nuxt/issues/20799",0.72795707,{"description":3260,"labels":3261,"number":3266,"owner":3146,"repository":3146,"state":3216,"title":3267,"updated_at":3268,"url":3269,"score":3270},"\u003C!-- 💚 Thanks for your time to make Nuxt better with your feedbacks 💚 -->\r\n\r\n### Is your feature request related to a problem? Please describe.\r\nMicro-frontend\r\n\r\n\u003C!-- A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] -->\r\n\r\n### Describe the solution you'd like\r\n\r\nHow about we warp the rendering and destruction process of the page into functions, and provide these functions to the users so they could decide when to call these functions. We only need to change the [client.js template](https://github.com/nuxt/nuxt.js/blob/dev/packages/vue-app/template/client.js) a little bit to implement this.\r\n\r\n\u003C!-- A clear and concise description of what you want to happen. Adding some code examples would be neat! -->\r\n\r\n### Describe alternatives you've considered\r\n\r\nNone\r\n\r\n\u003C!-- A clear and concise description of any alternative solutions or features you've considered. -->\r\n\r\n### Additional context\r\n\r\nNone\r\n\r\n\u003C!-- Add any other context or screenshots about the feature request here. -->\r\n\r\nHi, nuxt maintainers. Thank you for building such a great community!\r\n\r\nI'm trying to build an application using micro-frontend. I have found some solutions like [single-spa](https://single-spa.js.org/) and [qiankun](https://qiankun.umijs.org/guide). (P.S. qiankun is based on single-spa)\r\n\r\nBoth of them require sub-applications to provide some lifecycle functions.\r\n\r\nSay `qiankun` as an example : it needs sub app to provide:\r\n1. A `mount` function used to render pages so that `qiankun` can control when the sub app is mount.\r\n2. A `unmount` function used to destroy instance so that `qiankun` can control when the sub app instance is close.\r\n\r\nWe can easily do it in `Vue` cause we could define when and how we create, mount or unmount the `vue instace`(see also the [example](https://qiankun.umijs.org/guide/tutorial#vue-micro-app)).\r\n\r\nIn `nuxt`, it's another case. These processes done by `nuxt` behind the scenes, so it's impossible to use `qiankun` with `nuxt` without changing the nuxt file. \r\n\r\nSo I have a proposal: how about we warp the rendering and destruction process of the page into functions, providing to the users so they could decide when to call these functions. We only need to change the [client.js template](https://github.com/nuxt/nuxt.js/blob/dev/packages/vue-app/template/client.js) a little bit to implement this.\r\n\r\nSee also the implemention of the nuxt module [nuxt-micro-frontend](https://github.com/FEMessage/nuxt-micro-frontend/blob/dev/lib/client.js) with a change of `client.js`.\r\n\r\nWDYT?",[3262,3263],{"name":3140,"color":3171},{"name":3264,"color":3265},"2.x","d4c5f9",8970,"What about support for micro-frontend framework with a little change of client.js template","2024-06-14T16:02:35Z","https://github.com/nuxt/nuxt/issues/8970",0.7322833,["Reactive",3272],{},["Set"],["ShallowReactive",3275],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$foHk-xbO-AjKDSptK__DfnqJ3iqcGWbXvEdZHBqm3tag":-1},"/nuxt/ui/4724"]