Repository navigation
Depend less on auto importsΒ #2232
Description
The history of auto import idea probably backs to Nuxt Components (an amazing initiative by @kevinmarrec) and then same time as Nuxt 3 development, thanks to @antfu, we adopted unimport.
Auto imports make the DX of writing any javascript code much more minimalistic by automatically injecting necessary import statements in the modules that need them which means full tree-shaking same as manually importing them.
However, over time, it also showed negative effects;
- When reading sources or docs it is less understandable without knowing the sources of all auto imports
- IDE support is still not perfect, we need a
preparestep to generate the types, and even after that, click to jump does not always go to the source, it goes to the intermediate file, - Some users/frameworks prefer explicitly over magical conventions.
- To save process cost, we skip auto imports for
node_modules, and it implies module authors take additional care of explicitly importing from#importsvirtual module.
I still love auto imports and like the ability to have them but also think we could depend less on them and keep it for advanced usage and users who already know what they are doing.
For Nitro 2.x auto import feature shall remain enabled an I think for the sake of backward compatibility, in Nitro 3.x, we might keep having #imports but deprecated. We might also think about making the auto import experience opt-in for direct nitro users. (subject to discussion, only an idea for now)
### Tasks
- [ ] Use explicit imports from their sources in docs (explicit `h3` imports)
- [ ] Update starter template to explicitly import from `nitropack/config`
- [ ] Find a more explicit alternative to `#imports` like `nitro/app` for longer term
- [ ] Investigate solution for pnpm dependency hoisting issues (one solution might be directly adding h3 as dep in starter)
Activity
MickL commentedon Mar 24, 2024
I wrote it already in some Nuxt issues but I would love auto imports being fully disabled by default + all the docs updated for the reasons you stated. Personally I see no benefits of having auto imports, but a lots of downsides.
Right now it is not clear to developers what actually comes from H3, what from Nitro, what from Nuxt and what from Vue.
I failed multiple times disabling auto imports within a Nuxt app as well as in a Nitro app: #2305
pi0 commentedon Mar 25, 2024
Thanks for your feedback @MickL. This decision for Nuxt should happen within a Nuxt-related discussion. We might consider disabling it by default for Nitro core but probably in 1-2 more next major versions progressively.
MickL commentedon Apr 4, 2024
Hoping to see auto imports disabled in v3 :)
bernhardberger commentedon Jun 30, 2024
This is gonna be fun down the line refactoring tons of projects and modules. β οΈ
DesignByOnyx commentedon Nov 11, 2024
I want to throw my +1 and 2Β’ on this and provide some more reasons why auto-imports cause more harm than good.
The only convenient auto-import I've experienced is for JSX syntax - and it's because it changes the actual syntax of the code you're writing. Everything else should be explicit - it's 100% deterministic this way, and you'd immediately close a dozen or more open tickets and never have to worry about it again.
EDIT: @bernhardberger - you wouldn't need to rewrite anything - just add import statements to the tops of files. Also, the change is going to come in a major version bump, which usually requires code updates. This is about the most low risk "breaking change" they could make.
antfu commentedon Nov 14, 2024
I think the reason why we have this discussion is that we agree that auto-import is not a silver bullet. While it provides interesting DX and possibilities like DI, it's indeed having some trade-offs. I agree that for Nitro to be more agnostic, it's better to deps less on it and be less opinionated - would be great to still be able to opt-in for some cases like Nuxt.
In terms of migration, I created an ESLint plugin that auto insert the import statements based on the unimport registry: https://github.com/antfu/eslint-plugin-unimport
I can set up an example repo when this is happening.
pi0 commentedon Nov 14, 2024
eslint plugin is so cool for an in-between solution love it!
bernhardberger commentedon Nov 14, 2024
I don't disagree with you, but I fear a major breakage in the ecosystem if auto imports were removed.. not really the stability and predictability nuxt/nitro users look for after all the vue3/nuxt3 fiasco.
If the ecosystem were to break on a massive scale again this might very well be the final straw for a bunch of users that opted to use Nuxt in commercial projects.
We know we'd likely be out if something even remotely close to that scale happens again. We'd need at least a preparation period of minimum 1 major version of deprecation here.
MickL commentedon Nov 14, 2024
Why not make auto-imports opt-out for Nuxt 4, but always set the opt-out option for new projects created with Nuxi, then disable them with Nuxt 5 but keep it opt-in?
pi0 commentedon Nov 14, 2024
So to clarify, this discussion is not to "remove" the auto imports feature of Nitro at all but to depend less on them.
Auto imports are super useful for people who know the sources and prefer the minimal experience.
bernhardberger commentedon Nov 14, 2024
That I can 100% agree with.
pi0 commentedon Nov 14, 2024
This proposal is to make auto-imports an opt-in feature for pure nitro (v3+) projects.
Locking the thread for now, thanks for all constructive feedbacks it certainly helped confirming the idea is into a right direction ππΌ