\n\nWhere I use config then, it shows me typing error.\nWhen I switch to the legacy tsconfig, typing issue are gone.\n\n### Additional context\n\n_No response_\n\n### Logs\n\n```shell-script\nTypecheck summary: \n\n\n\napp/layouts/default.vue:35:33 - error TS2339: Property 'title' does not exist on type '{}'.\n\n35 title: appConfig.information?.title,\n ~~~~~\n\napp/layouts/default.vue:36:39 - error TS2339: Property 'description' does not exist on type '{}'.\n\n36 description: appConfig.information?.description,\n ~~~~~~~~~~~\n\napp/layouts/default.vue:39:36 - error TS2339: Property 'socials' does not exist on type '{}'.\n\n39 github: appConfig.information?.socials?.github,\n ~~~~~~~\n\napp/layouts/default.vue:40:38 - error TS2339: Property 'socials' does not exist on type '{}'.\n\n40 linkedin: appConfig.information?.socials?.linkedin,\n ~~~~~~~\n\napp/layouts/default.vue:41:40 - error TS2339: Property 'birthdate' does not exist on type '{}'.\n\n41 isBirthday: appConfig.information?.birthdate ? isBirthday(appConfig.information?.birthdate) : false,\n ~~~~~~~~~\n\napp/layouts/default.vue:41:86 - error TS2339: Property 'birthdate' does not exist on type '{}'.\n\n41 isBirthday: appConfig.information?.birthdate ? isBirthday(appConfig.information?.birthdate) : false,\n ~~~~~~~~~\n\napp/layouts/default.vue:44:27 - error TS2339: Property 'icons' does not exist on type '{}'.\n\n44 normal: appConfig.ui?.icons?.normal as string[] ?? [],\n ~~~~~\n\napp/layouts/default.vue:45:29 - error TS2339: Property 'icons' does not exist on type '{}'.\n\n45 birthday: appConfig.ui?.icons?.birthday as string[] ?? [],\n ~~~~~\n\napp/middleware/title.global.ts:5:28 - error TS2571: Object is of type 'unknown'.\n\n5 const appConfigTitle = useAppConfig().information.title;\n ~~~~~~~~~~~~~~~~~~~~~~~~~~\n\napp/pages/index.vue:14:62 - error TS2339: Property 'messages' does not exist on type '{}'.\n\n14 const messages = useState('randomIndex', () => appConfig.ui?.messages?.sort(() => Math.random() - 0.5))\n ~~~~~~~~\n\nnuxt.schema.ts:3:16 - error TS2304: Cannot find name 'defineNuxtSchema'.\n\n3 export default defineNuxtSchema({\n ~~~~~~~~~~~~~~~~\n\nnuxt.schema.ts:3:16 - error TS2304: Cannot find name 'defineNuxtSchema'.\n\n3 export default defineNuxtSchema({\n ~~~~~~~~~~~~~~~~\n\nnuxt.schema.ts:3:16 - error TS2304: Cannot find name 'defineNuxtSchema'.\n\n3 export default defineNuxtSchema({\n ~~~~~~~~~~~~~~~~\n```",[3018,3021],{"name":3019,"color":3020},"pending triage","E99695",{"name":3022,"color":3023},"possible regression","B90A42",32768,"nuxt","open","useAppConfig lose types from nuxt schema with new tsconfig","2025-07-25T22:51:01Z","https://github.com/nuxt/nuxt/issues/32768",0.6687238,{"description":3032,"labels":3033,"number":3040,"owner":3025,"repository":3041,"state":3026,"title":3042,"updated_at":3043,"url":3044,"score":3045},"### 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.",[3034,3037],{"name":3035,"color":3036},"question","d876e3",{"name":3038,"color":3039},"v3","49DCB8",4148,"ui","Additional props like variants for styling","2025-05-14T12:47:31Z","https://github.com/nuxt/ui/issues/4148",0.6771005,{"description":3047,"labels":3048,"number":3055,"owner":3025,"repository":3025,"state":3026,"title":3056,"updated_at":3057,"url":3058,"score":3059},"### Describe the feature\r\n\r\nHi :wave: , \r\nIt would be nice to be able to use `useAppConfig` within modules since this can be used by modules to get non-stringifyable data in plugins. \r\n\r\nCurrently there's like a dependency loop when we import an `app.config.ts` (in a module file) with \r\n\r\n````ts\r\nimport { defineAppConfig } from \"nuxt/app\"\r\nexport default defineAppConfig({ /* ..... */ })\r\n````\r\nif we don't specify the import, the import will fail since `app.config.ts` has not been transformed.\r\n\r\nusing `useAppConfig()` in modules triggers the same issue since it need to be imported from `nuxt/app`\r\n\r\n### Additional information\r\n\r\n- [ ] 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).",[3049,3052],{"name":3050,"color":3051},"documentation","5319e7",{"name":3053,"color":3054},"🍰 p2-nice-to-have","0E8A16",18762,"Allow sharing app config with build-time modules","2024-06-30T11:09:31Z","https://github.com/nuxt/nuxt/issues/18762",0.68623966,{"description":3061,"labels":3062,"number":3068,"owner":3025,"repository":3041,"state":3069,"title":3070,"updated_at":3071,"url":3072,"score":3073},"### 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```",[3063,3064,3065],{"name":3035,"color":3036},{"name":3038,"color":3039},{"name":3066,"color":3067},"stale","ededed",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.6619121,{"description":3075,"labels":3076,"number":3077,"owner":3025,"repository":3078,"state":3069,"title":3079,"updated_at":3080,"url":3081,"score":3082},"##error message\r\n\r\n ERROR(vue-tsc) Property 'nuxtIcon' does not exist on type 'AppConfig'.\r\nconst props = defineProps({\r\n name: {\r\n type: String as PropType\u003Ckeyof AppConfig['nuxtIcon']['aliases'] | (string & {})>,\r\n ^^^^^^^^^^\r\n required: true\r\n },\r\n\r\n##code\r\n\r\n```ts\r\n\r\nexport default defineNuxtConfig({\r\n srcDir: 'src',\r\n ssr: false,\r\n typescript: {\r\n typeCheck: true\r\n },\r\n modules: ['@nuxtjs/tailwindcss', 'nuxt-icon']\r\n\r\n})\r\n```",[],46,"icon","Error something on nuxt 3.1.0 - ERROR(vue-tsc) Property 'nuxtIcon' does not exist on type 'AppConfig'.","2023-01-27T14:11:31Z","https://github.com/nuxt/icon/issues/46",0.6647773,{"description":3084,"labels":3085,"number":3087,"owner":3025,"repository":3025,"state":3069,"title":3088,"updated_at":3089,"url":3090,"score":3091},"### Environment\n\n- Operating System: `Darwin`\r\n- Node Version: `v20.9.0`\r\n- Nuxt Version: `3.13.1`\r\n- CLI Version: `3.13.1`\r\n- Nitro Version: `2.9.7`\r\n- Package Manager: `pnpm@9.3.0`\r\n- Builder: `-`\r\n- User Config: `compatibilityDate`, `devtools`\r\n- Runtime Modules: `-`\r\n- Build Modules: `-`\r\n\n\n### Reproduction\n\nhttps://stackblitz.com/edit/github-yd89uq?file=app.vue,components%2FFoo.vue,components%2FBar.vue\n\n### Describe the bug\n\nI've noticed a few issues with component props after updating from Nuxt 3.12.3 to the latest version. I suspect it might be caused by enabling reactive props destructuring by default in Vue 3.5.\r\n\r\n1. setting default values for `boolean` props doesn't work (though it does for `string` props, for example)\r\n```ts\r\nconst {\r\n foo = true, // will be `false` if not provided\r\n bar = 'something', // will be `'something'` if not provided\r\n} = defineProps\u003C{\r\n foo?: boolean\r\n bar?: string\r\n}>()\r\n```\r\n2. seemingly, all prop reactivity is lost when using reactive destructure (when changing the prop values, they do not update in the component)\r\n```ts\r\n// It works correctly if defined using the \"old\" way, though\r\nconst props = defineProps\u003C{\r\n foo?: boolean\r\n bar?: string\r\n}>()\r\n```\r\n\r\n---\r\n\r\nThe behaviour was the same whether or not I had `vite.vue.script.propsDestructure` set to `true` in `nuxt.config` (though it should not be relevant now that it should be enabled by default?)\n\n### Additional context\n\nI tested it in vue SFC playground and it worked correctly there, so that's why I assume this might be a Nuxt issue\r\n\r\nhttps://play.vuejs.org/#eNqNUlFLwzAQ/ishLyqMFpm+zG6iMkEfdKiPAanttWamuZCkdTD6372kdA5x4tvd9313/fJdt/zKmKRrgc945gorjWcOfGsWQsvGoPXsBhvDKosNO0rS0AT50YXQQmfpMEJiajw0RuUeqGMsK2UXCyrjhnSA0wHP0j01n3DvCtSVrJO1Q01etkEseEGTUoF9NF6idoLPWGQClyuFn/cR87aFyYgX71B8/IKv3SZggq8sOLAdCL7jfG5r8AO9fH6ADdU7ssGyVaT+g3wCh6oNHgfZdatLsr2ni27vYqJS1y9uufGg3fioYDQo+6gXnBIOoR16+rfdaXIW54TuKcXxOj+PyVSu6znN0Zp4Kwrb+WFfhcjmY1I9lSVUUsPKonHZqLicsTdEBTnN9ovjk/8f/xaRjG/jZ3qyefgXeO3AhkDI/DQ5T055/wUEUtzf\n\n### Logs\n\n_No response_",[3086],{"name":3019,"color":3020},28845,"Issues with prop reactivity & default values when using reactive props destructure","2024-09-05T10:11:34Z","https://github.com/nuxt/nuxt/issues/28845",0.66570497,{"description":3093,"labels":3094,"number":3102,"owner":3025,"repository":3025,"state":3069,"title":3103,"updated_at":3104,"url":3105,"score":3106},"### Environment\r\n\r\n- Operating System: Linux\r\n- Node Version: v18.20.3\r\n- Nuxt Version: 3.13.1\r\n- CLI Version: 3.13.1\r\n- Nitro Version: 2.9.7\r\n- Package Manager: npm@10.2.3\r\n- Builder: -\r\n- User Config: compatibilityDate, devtools\r\n- Runtime Modules: -\r\n- Build Modules: -\r\n\r\n### Reproduction\r\n\r\nhttps://stackblitz.com/edit/github-t1vjvm?file=components%2Fcomp.vue,app.vue\r\n\r\n### Describe the bug\r\n\r\nDefining props with default value using the new vue 3.5 props destructure is compiled differently in nuxt.\r\n\r\nIn the [vue playground (vue3.5.1, SSR)](https://play.vuejs.org/#__SSR__eNp9Uk1Lw0AQ/SvjXmqhpEj1UpOKSkE9aFHBy4LEZBJTN7vL7qYWQv67sxtbU1BPycx7s+/NR8sutY42DbI5i21mKu3Aomv0gsuq1so4uFa1hsKoGkbR1AeePjrf4y0YLKD7pniMSy4zJa2D2paQePx4dINCKHhRRuRHozGX8bSXIyEKHNZapA4pAoi9yiIOYpSIpwOUTZiz9HhRldHaKkm+W1/DWUbsSqB50K4icc7mEBCPpaT9eRdyzjQ42eWzd8w+fsmv7dbnOFsZtGg2yNkec6kp0fXw8uket/S/B2uVN4LY/4CPaJVovMeedtXInGwPeMHtbZhuJctnu9w6lHbXlDfqmV3gc0YT94P6q/Ufu7PoNNRx2dEUd5v0iz+YfttCoRR0xDuYPIXDAwGRyjKh90mO0H7ffWkSPNJJJJBjUUlcGaVtHCwRfjGHN6UEppKOqFscj+kzuAby9rpB4/slb7PoLDph3RcS1OLs):\r\n\r\n\r\n\r\n```js\r\n/* Analyzed bindings: {\r\n \"foo\": \"props\"\r\n} */\r\nimport { defineComponent as _defineComponent } from 'vue'\r\n\r\nconst __sfc__ = /*@__PURE__*/_defineComponent({\r\n __name: 'Comp',\r\n props: {\r\n foo: { type: Boolean, required: false, default: true }\r\n },\r\n setup(__props, { expose: __expose }) {\r\n __expose();\r\n\r\n\r\n\r\nconst __returned__ = { }\r\nObject.defineProperty(__returned__, '__isScriptSetup', { enumerable: false, value: true })\r\nreturn __returned__\r\n}\r\n\r\n});\r\nimport { ssrInterpolate as _ssrInterpolate } from \"vue/server-renderer\"\r\nfunction ssrRender(_ctx, _push, _parent, _attrs, $props, $setup, $data, $options) {\r\n _push(`${_ssrInterpolate($props.foo)}`)\r\n}\r\n__sfc__.ssrRender = ssrRender\r\n__sfc__.__file = \"src/Comp.vue\"\r\nexport default __sfc__\r\n```\r\n\r\nIn Nuxt:\r\n\r\n\r\n```js\r\nimport { createHotContext as __vite__createHotContext } from \"/_nuxt/@vite/client\";import.meta.hot = __vite__createHotContext(\"/components/comp.vue\");import { defineComponent as _defineComponent } from \"/_nuxt/node_modules/vue/dist/vue.runtime.esm-bundler.js?v=8fea97c8\";\r\nconst _sfc_main = /* @__PURE__ */ _defineComponent({\r\n __name: \"comp\",\r\n props: {\r\n foo: { type: Boolean, required: false }\r\n },\r\n setup(__props, { expose: __expose }) {\r\n __expose();\r\n const { foo = true } = __props;\r\n const __returned__ = { foo };\r\n Object.defineProperty(__returned__, \"__isScriptSetup\", { enumerable: false, value: true });\r\n return __returned__;\r\n }\r\n});\r\nimport { toDisplayString as _toDisplayString } from \"/_nuxt/node_modules/vue/dist/vue.runtime.esm-bundler.js?v=8fea97c8\";\r\nfunction _sfc_render(_ctx, _cache, $props, $setup, $data, $options) {\r\n return _toDisplayString($setup.foo);\r\n}\r\n_sfc_main.__hmrId = \"ea5b442f\";\r\ntypeof __VUE_HMR_RUNTIME__ !== \"undefined\" && __VUE_HMR_RUNTIME__.createRecord(_sfc_main.__hmrId, _sfc_main);\r\nimport.meta.hot.accept((mod) => {\r\n if (!mod) return;\r\n const { default: updated, _rerender_only } = mod;\r\n if (_rerender_only) {\r\n __VUE_HMR_RUNTIME__.rerender(updated.__hmrId, updated.render);\r\n } else {\r\n __VUE_HMR_RUNTIME__.reload(updated.__hmrId, updated);\r\n }\r\n});\r\nimport _export_sfc from \"/_nuxt/@id/__x00__plugin-vue:export-helper\";\r\nexport default /* @__PURE__ */ _export_sfc(_sfc_main, [[\"render\", _sfc_render], [\"__file\", \"/home/projects/github-t1vjvm/components/comp.vue\"]]);\r\n```\r\n\r\n### Additional context\r\n\r\n_No response_\r\n\r\n### Logs\r\n\r\n_No response_",[3095,3098,3101],{"name":3096,"color":3097},"workaround available","11376d",{"name":3099,"color":3100},"bug","d73a4a",{"name":3053,"color":3054},28829,"reactive props destructure with default values doesn't work","2024-09-24T15:17:28Z","https://github.com/nuxt/nuxt/issues/28829",0.6725274,{"description":3108,"labels":3109,"number":3119,"owner":3025,"repository":3025,"state":3069,"title":3120,"updated_at":3121,"url":3122,"score":3123},"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",[3110,3113,3116],{"name":3111,"color":3112},"enhancement","8DEF37",{"name":3114,"color":3115},"discussion","538de2",{"name":3117,"color":3118},"3.x","29bc7f",15592,"Custom config schema","2023-04-07T01:47:49Z","https://github.com/nuxt/nuxt/issues/15592",0.6751535,{"description":3125,"labels":3126,"number":3128,"owner":3025,"repository":3025,"state":3069,"title":3129,"updated_at":3130,"url":3131,"score":3132},"### Environment\r\n\r\n------------------------------\r\n- Operating System: Windows_NT\r\n- Node Version: v20.10.0\r\n- Nuxt Version: 3.10.3\r\n- CLI Version: 3.10.1\r\n- Nitro Version: 2.9.1\r\n- Package Manager: npm@10.2.3\r\n- Builder: -\r\n- User Config: devtools\r\n- Runtime Modules: -\r\n- Build Modules: -\r\n------------------------------\r\n\r\n### Reproduction\r\n\r\nhttps://stackblitz.com/edit/nuxt-starter-zges3w?file=types%2Fapp.config.d.ts,app.vue,types%2Fvariables.d.ts\r\n\r\n### Describe the bug\r\n\r\nWhen referencing `theme` from `useAppConfig`, typescript should **always** allow both the `primary` and `secondary` type as possible values.\r\n\r\nThis should be possible by overriding the App Config Output as described here: https://nuxt.com/docs/guide/directory-structure/app-config#app-config-output.\r\n\r\nHowever, that does not work when using `extends` and only works when the `AppConfig` interface has the overriding types explicitly written out.\r\n\r\nStackblitz doesn't visibly show the error, but VS Code with the volar extensions does:\r\n\r\n\r\n### Additional context\r\n\r\nI use this pattern in a monorepo where there is a `base` layer with components that take in the config set by child sites.\r\n\r\nThis **does** work if `export {};` is **not** declared after `declare module '@nuxt/schema'`. However this will break types in `nuxt.config.ts`\r\n\r\n### Logs\r\n\r\n_No response_",[3127],{"name":3019,"color":3020},26116,"interface AppConfig does not take types when using `extends`","2024-12-16T12:46:25Z","https://github.com/nuxt/nuxt/issues/26116",0.6765612,{"description":3134,"labels":3135,"number":3139,"owner":3025,"repository":3041,"state":3069,"title":3140,"updated_at":3141,"url":3142,"score":3143},"### 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_",[3136,3138],{"name":3111,"color":3137},"a2eeef",{"name":3038,"color":3039},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.6788868,["Reactive",3145],{},["Set"],["ShallowReactive",3148],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$fTZRX3aApajvfK1QpQD4jS0GNdOqKOFgGiDZvIL6dbYA":-1},"/nuxt/ui/2662"]