@@TheAlexLichter Many reasons. I explained them more detailed in the comment below. But most important, I don't see at least one reason why having explicit imports could hurt anyone. Having them has many benefits, but not having them has none. The "noise" argument is not relevant if IDE can collapse imports by default. I agree that this is not perfectly implemented by VS Code (it doesn't automatically unfold when you click or try to edit the import; hotkeys to fold/unfold are also very inconvenient by default). IDEA does much better job here. But, anyway, this should be solved by IDE, not by implicit imports. And even without auto-folding having that "noise" is a small price to pay for allowing you (or other team member who opens this file first time in his life) to quicky understand all the dependencies without reading the whole code. Naming conflicts are easier to solve too (they are explicit, so force you to do something beforehand). Code organization (I would like to organize my project not by type of the file, but by feature, so components/composables can live anywhere). Most of these things are configurable of course, but default config makes you think (especially if you are not very experienced developer) that this is the best practice, while it is not. For a demo/todo-list projects, maybe yes. But not for any real-world project that you are expecting to be maintained for years. I'm not saying that having auto-imports automatically do your project unmanageable of course. :) But it makes it harder to maintain. Especially if future you don't remember anything about this project. :)
Love that people have a choice to use it, hate that it is opt out. Not for me, I think the noise of imports are actually important signals to observe certains patterns. Good move by pi0 to make it opt-in
Happy Birthday! My preference is to have auto-imports only mostly on Vue things as it should be universally understood what a ref is to a Vue developer, but out of convenience also use it for Nuxt components and composables as it doesn't feel much better to explicitly import them from '#imports' or '#components'. If Nuxt had as clean of explicit imports as Next.js does, I'd consider turning auto-imports off completely. Auto imports from modules can also be tricky at times, for instance when the module author expects you to use auto imports mechanism, leaving no other choice than reaching for '#imports' if you want to use explicit imports.
First of all, happy birthday :) I like Nuxt Autoimports and work with it in large applications (with several Nuxt layers). We don't often rename our files, but we do often sort the files in the components folder (atomic design). It just takes me less time with auto imports than if I have to do it manually first (a small component can be used in many other components). The same applies when we deactivate components for testing purposes, otherwise the import has to disappear otherwise ESLint will complain.
Autoimports are pure evil, and the project's size doesn't matter at all. I hope Nuxt outgrows this childish trauma and starts removing this feature. Autoimports complicate refactoring, confuse the IDE (hello imports.d.ts), and require running nuxt prepare. When imports are explicitly defined, it also helps to understand whether the current file is overloaded and needs decomposition. If imports in the code bother you so much, the IDE can easily hide them from the UI. Please prefer the explicit over the implicit 🙏
There is an open issue for that! Nitro is already removing them, hoping Nuxt will do the same for v4. I totally agree with you, auto imports are the worst thing every in so many way and provide zero benifits. Every modern IDE already provides "auto imports" by automatically adding and updating them and even hiding them if you dont need so see them atm.
Happy birthday! I like to auto-import the boring stuff like the stuff from vue or next and also composable and utility functions and the 3rd party stuff that used a lot like i18n. For components I don't like the path-prefix at all. I prefer to import components using alias specially when using next layers (to be more explicit)
I'm team auto-import all the way. The argument about refactoring support in the IDE is the only real downside for me. As for wondering where stuff comes from, it takes less time to click or hover the function to find its origin than it takes to scroll up, look through all the imports and find what you're looking for in my opinion :) And without auto-imports a linter on auto-save is pretty much required to keep imports clean (good idea to have one anyway but still).
If you have explicit imports you can still click into functions? Actually even better, you end up in the real function not in the unnecessary imports.d.ts file… Auto imports are the worst, they only have downsides and provide zero benifits. Every modern IDE automatically adds imports and keeps them up to date and hides them if you dont see them.
@Andrew-tl9gk You are repeating yourself and not everyone uses IDEs or wants to use them, a large proportion use code editors such as VSCode, Vim or Emacs. And IDEs only add imports, but can't automatically remove them if you either remove or comment out a component in the template (for testing) the result ESlint will complain.
I refused to use auto imports in Nuxt/Vue, ‘cause it’s very difficult to maintain big projects that need custom structure. Try FSD-like app architecture and you will understand that it will be pain in the ass with auto imports. I’m also not using auto imports, ‘cause it’s more clear way to see what you import in your component instead of blind using something
Happy Birthday! Great video but any chance you look into disabling the youtube auto translation thingi? so everyone can hear your voice by default and not the AI
@@TheAlexLichter This one still started in spanish. I can change the track sound but the everything else still translated. BADLY. This video is about "Importaciones de automóviles", holy crap.
Great explanation, but I personally don't like auto imports. While they reduce boilerplate, they make it harder to track where things come from, especially in large projects. Onboarding new team members and refactoring can also become a hassle. Sometimes, explicit imports just feel more reliable!
Hoping they get removed! IDEs nowadays hide imports if you dont click into them and automatically add them or refactor them if you rename/move files. So basically you already have "auto imports" in your IDE. It is absolutely horrible to use Nuxt and not know if a function comes from H3, Nitro, Nuxt or Vue. Auto imports have absolutely zero benifits but tons of downsites. Every other framework uses explicit imports, also in their docs. P.S. There is an open issue for removing them. Please upvote if you think the same way! Nitro is already removing them, hope Nuxt will follow.
Then maybe you use a bad IDE? Because my IDE is automatically adding imports for me and keeping them up to date. So basically my IDE is providing "auto imports". The auto imports Nuxt provide bring tons of downsides but zero benifits. I hope they get removed with v4!
Whoops, seems like the camera was already in party mode in the last third. 🙈
Still - are you a fan of auto imports or hate them?
Hate them.
@djxak why?
@@TheAlexLichter Many reasons. I explained them more detailed in the comment below.
But most important, I don't see at least one reason why having explicit imports could hurt anyone. Having them has many benefits, but not having them has none. The "noise" argument is not relevant if IDE can collapse imports by default. I agree that this is not perfectly implemented by VS Code (it doesn't automatically unfold when you click or try to edit the import; hotkeys to fold/unfold are also very inconvenient by default). IDEA does much better job here. But, anyway, this should be solved by IDE, not by implicit imports.
And even without auto-folding having that "noise" is a small price to pay for allowing you (or other team member who opens this file first time in his life) to quicky understand all the dependencies without reading the whole code. Naming conflicts are easier to solve too (they are explicit, so force you to do something beforehand). Code organization (I would like to organize my project not by type of the file, but by feature, so components/composables can live anywhere).
Most of these things are configurable of course, but default config makes you think (especially if you are not very experienced developer) that this is the best practice, while it is not. For a demo/todo-list projects, maybe yes. But not for any real-world project that you are expecting to be maintained for years. I'm not saying that having auto-imports automatically do your project unmanageable of course. :) But it makes it harder to maintain. Especially if future you don't remember anything about this project. :)
Love that people have a choice to use it, hate that it is opt out. Not for me, I think the noise of imports are actually important signals to observe certains patterns. Good move by pi0 to make it opt-in
Congratulations, Alex! 🎉
Happy Birthday!
My preference is to have auto-imports only mostly on Vue things as it should be universally understood what a ref is to a Vue developer, but out of convenience also use it for Nuxt components and composables as it doesn't feel much better to explicitly import them from '#imports' or '#components'. If Nuxt had as clean of explicit imports as Next.js does, I'd consider turning auto-imports off completely.
Auto imports from modules can also be tricky at times, for instance when the module author expects you to use auto imports mechanism, leaving no other choice than reaching for '#imports' if you want to use explicit imports.
First of all, happy birthday :)
I like Nuxt Autoimports and work with it in large applications (with several Nuxt layers). We don't often rename our files, but we do often sort the files in the components folder (atomic design). It just takes me less time with auto imports than if I have to do it manually first (a small component can be used in many other components). The same applies when we deactivate components for testing purposes, otherwise the import has to disappear otherwise ESLint will complain.
Autoimports are pure evil, and the project's size doesn't matter at all. I hope Nuxt outgrows this childish trauma and starts removing this feature.
Autoimports complicate refactoring, confuse the IDE (hello imports.d.ts), and require running nuxt prepare. When imports are explicitly defined, it also helps to understand whether the current file is overloaded and needs decomposition. If imports in the code bother you so much, the IDE can easily hide them from the UI.
Please prefer the explicit over the implicit 🙏
There is an open issue for that! Nitro is already removing them, hoping Nuxt will do the same for v4.
I totally agree with you, auto imports are the worst thing every in so many way and provide zero benifits. Every modern IDE already provides "auto imports" by automatically adding and updating them and even hiding them if you dont need so see them atm.
Brother, your content is great. You explain things that people normally ask because they only use it. Thank you very much for explaining these things.
I’ve gone back and forth on this so many times
Hope you could decide after the video? 👀☺️
Happy birthday!
I like to auto-import the boring stuff like the stuff from vue or next and also composable and utility functions and the 3rd party stuff that used a lot like i18n.
For components I don't like the path-prefix at all.
I prefer to import components using alias specially when using next layers (to be more explicit)
Happy Birthday alex🎉🎉
Thank you so much 🙏🏻
Happy Birthday alex 🎉🎂, thankyou for sharing!
Thank you so much ☺️🙏🏻
Hey Alex, happy birthday!
Thank you 🙏🏻
I'm team auto-import all the way. The argument about refactoring support in the IDE is the only real downside for me. As for wondering where stuff comes from, it takes less time to click or hover the function to find its origin than it takes to scroll up, look through all the imports and find what you're looking for in my opinion :) And without auto-imports a linter on auto-save is pretty much required to keep imports clean (good idea to have one anyway but still).
If you have explicit imports you can still click into functions? Actually even better, you end up in the real function not in the unnecessary imports.d.ts file…
Auto imports are the worst, they only have downsides and provide zero benifits. Every modern IDE automatically adds imports and keeps them up to date and hides them if you dont see them.
@Andrew-tl9gk You are repeating yourself and not everyone uses IDEs or wants to use them, a large proportion use code editors such as VSCode, Vim or Emacs. And IDEs only add imports, but can't automatically remove them if you either remove or comment out a component in the template (for testing) the result ESlint will complain.
Happy Birthday my dude!
Thanks! 🎉
Happy birthday bro
Thank you 🙏🏻
I refused to use auto imports in Nuxt/Vue, ‘cause it’s very difficult to maintain big projects that need custom structure. Try FSD-like app architecture and you will understand that it will be pain in the ass with auto imports.
I’m also not using auto imports, ‘cause it’s more clear way to see what you import in your component instead of blind using something
There is an open issue in Nuxt github, maybe give it an upvote!
Hope you had a great birthday 🎉
Happy Birthday!
Great video but any chance you look into disabling the youtube auto translation thingi?
so everyone can hear your voice by default and not the AI
Thank you!!
I thought I already disabled it by default 🫠
Will check!
@@TheAlexLichter
This one still started in spanish. I can change the track sound but the everything else still translated. BADLY. This video is about "Importaciones de automóviles", holy crap.
@PabloRodriguez-su4gp Somehow the defaults got changed again. Fixed!
Bro how tf do I turn off audio translation
Disabled it (thought I had already)
Nice it now is thanks!@@TheAlexLichter
Happy birthday 🎉 🎂
Thanks ☺️🙏🏻
Happy bday!
Thanks ☺️🙏🏻
Great explanation, but I personally don't like auto imports. While they reduce boilerplate, they make it harder to track where things come from, especially in large projects. Onboarding new team members and refactoring can also become a hassle. Sometimes, explicit imports just feel more reliable!
"onboarding yourself a week after writing code" 🤣🤣🤣
It's true, isn't it? 👀
@@TheAlexLichter 💯
Конечно то, что выключено по умолчанию это плохо.
Hoping they get removed! IDEs nowadays hide imports if you dont click into them and automatically add them or refactor them if you rename/move files. So basically you already have "auto imports" in your IDE. It is absolutely horrible to use Nuxt and not know if a function comes from H3, Nitro, Nuxt or Vue. Auto imports have absolutely zero benifits but tons of downsites. Every other framework uses explicit imports, also in their docs.
P.S. There is an open issue for removing them. Please upvote if you think the same way! Nitro is already removing them, hope Nuxt will follow.
My thoughts (and deep dive) are on my blog (YT preventing me from pasting link here) but TL;DR: disable path prefixing and they're pretty great
^ davestewart.co.uk/blog/nuxt-auto-import/
Thanks Alex, and Happy Birthday!
I couldn't live without auto imports. The only downside for me is not being able to jump to components without a vscode extension.
Then maybe you use a bad IDE? Because my IDE is automatically adding imports for me and keeping them up to date. So basically my IDE is providing "auto imports". The auto imports Nuxt provide bring tons of downsides but zero benifits. I hope they get removed with v4!
@@Andrew-tl9gk I use Nuxt with VSCode and a plugin from Anthony Fu to jump to components
happy bday!
Thank you 🙏🏻