\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).",[3020,3023],{"name":3021,"color":3022},"enhancement","8DEF37",{"name":3024,"color":3025},"pending triage","E99695",29275,"nuxt","open","Better API for Auto Imports Customization","2024-10-08T08:40:01Z","https://github.com/nuxt/nuxt/issues/29275",0.76456875,{"description":3034,"labels":3035,"number":3040,"owner":3027,"repository":3027,"state":3028,"title":3041,"updated_at":3042,"url":3043,"score":3044},"### Describe the feature\n\nI could not find anywhere in the docs any _explanation_ as to why you should not import Vue app code in your Nitro code (or the other way around). I only found statements that you should **never** do this. But didn't find any reasons given. This, I think will cause a lot of users to simply ignore the warning because they don't see any problems with it.\n\nI found a couple of places where the warning is given, for example here: https://nuxt.com/blog/v3-14#shared-folder-for-code-and-types-shared-with-clientserver\n\n> You should never import Vue app code in your nitro code (or the other way around). \n\nAnd also here: https://nuxt.com/docs/guide/directory-structure/shared\n\n> Code in the shared/ directory cannot import any Vue or Nitro code.\n\nBut it doesn't explain **why**. What bad thing will happen if you do? Will something break or not work? What is the reason? Of course you cannot import components or composables in Nitro - that would make no sense. But what about types? Because right now you can import things from your Vue app inside your server app and things seem to work just as fine.\n\nEven in our own project we have this import and things seem to work:\n\n```ts\n// Imports from Vue inside Nitro\nimport type { ApiFragment } from '~/common/types/api'\nimport type { GlobalSearchResults } from '~/common/types/graphql/graphql'\n\nexport default defineEventHandler(async (event): Promise\u003CGlobalSearchResults> => {\n //\n}\n```\n\nI would be willing to send in the PR for this if I knew the deeper reasons myself. It would be very helpful to add a little explanation in the docs.\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).",[3036,3039],{"name":3037,"color":3038},"documentation","5319e7",{"name":3024,"color":3025},30862,"docs: add reason for why you should never import Vue app code in your nitro code","2025-02-05T14:52:52Z","https://github.com/nuxt/nuxt/issues/30862",0.76761425,{"description":3046,"labels":3047,"number":3055,"owner":3027,"repository":3027,"state":3028,"title":3056,"updated_at":3057,"url":3058,"score":3059},"### Environment\r\n\r\nNuxt project info: 11:21:16 AM\r\n\r\n------------------------------\r\n- Operating System: Linux\r\n- Node Version: v20.11.1\r\n- Nuxt Version: 3.11.1\r\n- CLI Version: 3.11.1\r\n- Nitro Version: 2.9.4\r\n- Package Manager: yarn@1.22.21\r\n- Builder: -\r\n- User Config: devtools, css, postcss, nitro, modules, vuefire\r\n- Runtime Modules: nuxt-vuefire@1.0.2\r\n- Build Modules: -\r\n------------------------------\r\n\r\n### Reproduction\r\n\r\nI created a class:\r\n\r\n```typescript\r\nimport FirestoreManager from './FirestoreManager';\r\nimport type { ArtworkType } from '~/utils';\r\n\r\nconst DB_NAME = 'artworks';\r\n\r\nclass ArtworkManager extends FirestoreManager\u003CArtworkType> {\r\n \r\n static instance: ArtworkManager;\r\n\r\n constructor(dbName: string) {\r\n if (ArtworkManager.instance) {\r\n return ArtworkManager.instance;\r\n }\r\n super(dbName);\r\n ArtworkManager.instance = this;\r\n }\r\n\r\n // Método estático para obtener la instancia\r\n static getInstance() {\r\n if (!ArtworkManager.instance) {\r\n ArtworkManager.instance = new ArtworkManager(DB_NAME);\r\n }\r\n return ArtworkManager.instance;\r\n }\r\n\r\n}\r\n\r\nexport { ArtworkManager }\r\n```\r\n\r\nTo get autoimport in `~/utils/index.ts` I exported it:\r\n\r\n```typescript\r\nexport { ArtworkManager } from './firebase/firestore/ArtworkManager';\r\n```\r\n\r\n\r\n\r\n### Describe the bug\r\n\r\nThe problem that I have is importing a class (singleton) from utils. \r\n\r\nI got this error:\r\n\r\n\r\nIt autoimports the class itself.\r\n\r\nIf I remove the export from `~/utils/index.ts` I got:\r\nThe requested module '/_nuxt/utils/index.ts?t=1711549824227' does not provide an export named 'ArtworkManager'\r\n\r\n\r\n\r\n### Additional context\r\n\r\nI tried to move the 'ArtworkManager' class to `~/utils/` root, but I got the same results.\r\n\r\n### Logs\r\n\r\n_No response_\r\n\r\n\r\n## Question\r\n\r\nIs it the correct way to do it? \r\nIf not, what is the correct way to autoimport a class?",[3048,3049,3052],{"name":3024,"color":3025},{"name":3050,"color":3051},"upstream","E8A36D",{"name":3053,"color":3054},"possible regression","B90A42",26516,"Identifier 'XXX' has already been declared, when I use a class","2025-06-01T13:33:03Z","https://github.com/nuxt/nuxt/issues/26516",0.77042156,{"description":3061,"labels":3062,"number":3066,"owner":3027,"repository":3067,"state":3068,"title":3069,"updated_at":3070,"url":3071,"score":3072},"Currently, nuxt-vitest declares vitest as a dependency. However, it is not possible to invoke binaries exposed by transitive dependencies (at least for yarn, see https://github.com/yarnpkg/berry/issues/1875). Thus users are forced to install vitest as well, so that you end up with two versions of vitest which might lead to version mismatches and issues such as https://github.com/danielroe/nuxt-vitest/issues/132.\r\n\r\nProposal:\r\n- Either make vitest a peer dependency\r\n- Re-expose the vitest binary in nuxt-vitest",[3063],{"name":3064,"color":3065},"vitest-environment","b60205",538,"test-utils","closed","Make vitest a peer dependency or expose vitest bin","2023-12-02T00:32:10Z","https://github.com/nuxt/test-utils/issues/538",0.46193996,{"labels":3074,"number":3081,"owner":3027,"repository":3027,"state":3068,"title":3082,"updated_at":3083,"url":3084,"score":3085},[3075,3078],{"name":3076,"color":3077},"3.x","29bc7f",{"name":3079,"color":3080},"bug","d73a4a",12847,"`isReactive` is not auto-imported","2023-01-19T16:37:30Z","https://github.com/nuxt/nuxt/issues/12847",0.7501394,{"labels":3087,"number":3090,"owner":3027,"repository":3027,"state":3068,"title":3091,"updated_at":3092,"url":3093,"score":3094},[3088,3089],{"name":3021,"color":3022},{"name":3076,"color":3077},14505,"allow disabling auto imports","2024-04-16T07:56:52Z","https://github.com/nuxt/nuxt/issues/14505",0.76330787,{"description":3096,"labels":3097,"number":3105,"owner":3027,"repository":3027,"state":3068,"title":3106,"updated_at":3107,"url":3108,"score":3109},"### Describe the feature\n\nI've been enjoying the DX of auto-imported components and composables ever since the release of those packages for Vue and I'm happy it's auto-configured for Nuxt.\r\n\r\nAs for the next step, would it be possible to **selectively** auto-import types? There's no point in auto-importing everything because large apps would just have too many types clogging the IDE and there would be naming collisions all over the place. But perhaps by adding a `.global` or `.auto` to a type file's name, exported types in those files could be safely auto-imported. It would certainly be a handy tool for those ubiquitous types that tend to sneak into many of your components.\r\n\r\nI'm sure there's pros and cons to this, so let's discuss 💬\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).",[3098,3099,3102],{"name":3021,"color":3022},{"name":3100,"color":3101},"discussion","538de2",{"name":3103,"color":3104},"🍰 p2-nice-to-have","0E8A16",27719,"Types auto-import","2024-08-09T09:39:34Z","https://github.com/nuxt/nuxt/issues/27719",0.7644108,{"description":3111,"labels":3112,"number":3118,"owner":3027,"repository":3027,"state":3068,"title":3119,"updated_at":3120,"url":3121,"score":3122},"Similar to modules for providing compatible [moduleContainer](https://github.com/nuxt/framework/blob/main/packages/kit/src/module/container.ts), we need the same for the app so that newly created utils and plugins can work in a nuxt/vue 2 context. We probably need a global module like `@nuxt/app/compat` to add such polyfill.\r\n\r\nFor composables, we have two options of having imports from `@nuxt/app/compat` or aliasing `@nuxt/app` to compat when compat module is in use. Downside is shadowing valid import and upside is that module and composable authors don't need to worry about importing from compat or non compat. One version they write works for both.\r\n\r\n\r\n(pending to stabilize app API first)",[3113,3114,3115],{"name":3100,"color":3101},{"name":3076,"color":3077},{"name":3116,"color":3117},"app","17512D",11424,"app compat","2023-01-19T15:38:24Z","https://github.com/nuxt/nuxt/issues/11424",0.7656367,{"labels":3124,"number":3129,"owner":3027,"repository":3027,"state":3068,"title":3130,"updated_at":3131,"url":3132,"score":3133},[3125,3126],{"name":3024,"color":3025},{"name":3127,"color":3128},"2.x","d4c5f9",8160,"Dynamic import not working!!","2023-01-22T15:38:17Z","https://github.com/nuxt/nuxt/issues/8160",0.76700956,{"description":3135,"labels":3136,"number":3142,"owner":3027,"repository":3027,"state":3068,"title":3143,"updated_at":3144,"url":3145,"score":3146},"### Describe the feature\n\ndisable certain module from auto import or we need to fully disable it ? we only like nuxt and vue3 autoimport not rest other library which carry vast amount of module #they are uncessary be using auto import feature to reduce the speed for startup application as reduce time on development mode \r\nfor example with ur quasar auto import component \r\n\r\n\r\n\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).",[3137,3138,3139],{"name":3076,"color":3077},{"name":3024,"color":3025},{"name":3140,"color":3141},"needs reproduction","FBCA04",24604,"auto import disable for for certain library ","2023-12-11T12:00:18Z","https://github.com/nuxt/nuxt/issues/24604",0.76836425,["Reactive",3148],{},["Set"],["ShallowReactive",3151],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$fHqSV-xFzki9a6qeZiHtOV2y88v_E9t81-mPEG6NObZc":-1},"/nuxt/nuxt.com/538"]