-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
feat(nuxt): imports.autoImport
option to disable auto-imports
#6768
Conversation
β Deploy Preview for nuxt3-docs ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
autoImports.enabled
allowing to disable auto-β¦autoImports.enabled
allowing to disable auto-import
```ts [nuxt.config.ts] | ||
export default defineNuxtConfig({ | ||
autoImports: { | ||
enabled: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think of calling option implicit: false
or global: false
(since we still have auto imports integration with #imports
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I kinda thought about that. My idea was:
implicit
might be a bit less intuitive as not everyone needs to know the existence of the explicit imports. Most of the time I feel the "Auto import" should refer to implicit auto import.- We picked the scope name of
autoImports
(with we went a bit beyond that tbh π),autoImports.enabled = false
sounds just like we are disabled the "auto" part. While the explicit import technically is not that "Auto" π€£
For more semantic meaning maybe we could reconsider the autoImports
scope naming.
But that said, I think implicit: false
could also be a good name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about mode: 'inject' | 'import'
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it but inject mode also allows import (ie: it is not switch between them but switch auto)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then what about something like: 'auto' | 'explicit' ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still auto means (auto + explicit). More i'm thinking, we could rename option to imports
, and then support imports.autoImport: false
.
Wow, thanks for looking into this, and so soon :) So, If i understand everything correctly, when the implicit auto import is disabled, With implicit auto import disabled, can I still use With implicit auto import disabled, what happens with imports from readonly defineNuxtComponent: UnwrapRef<typeof import('../../node_modules/nuxt/dist/app')['defineNuxtComponent']>
readonly defineNuxtLink: UnwrapRef<typeof import('../../node_modules/nuxt/dist/app')['defineNuxtLink']>
readonly defineNuxtPlugin: UnwrapRef<typeof import('../../node_modules/nuxt/dist/app')['defineNuxtPlugin']>
readonly defineNuxtRouteMiddleware: UnwrapRef<typeof import('../../node_modules/nuxt/dist/app')['defineNuxtRouteMiddleware']> Again, thanks for looking into this. Looking forward to use Nuxt 3, and even more with this feature. |
Yes
I would suggest setting an ESLint rule for that if you strictly want that.
They are equivalent in the bundle.
It's recommended to use |
Found this PR while doing package selection for choosing Nuxt as possible framework for a future project. What I'm focussing on; finding a framework that adopts common coding best practices related to SOLID principles. In what situation would the concept of The great news is that auto-imports seem to make it drastically easier for beginning developers to build stuff, but also can be considered as a direct violation to the dependency inversion priniciple. Having a huge The feature in this PR thereby possibly could be considered as a must-have before the major release? Has it been considered in what way the introduction of auto-imports would (also negatively) impact the framework future? An interesting topic to read about is how in the land of PHP the Laravel framework Facades do opinionate development and thereby made two camps. So, although the topic obviously might be out of scope of this PR, the question to ask is in what way Nuxt can on the one hand simplify development by supporting features like auto-imports, while on the other hand drive adoption of commonly accepted development principles like decent dependency injection. It is not strange that DI containers like InversifyJS do so well on Github with 9.2k stars. PSR-11 is a great example of what Nuxt could also do. What about, instead of silently enabling auto-imports and forcing engineers to use auto-imports, as a framework giving the developer freedom of choice? Nuxt coud support the embedding of a DI container in Nuxt, while also giving them the other option to enable auto-imports? It could be as simple as a container interface or facade, and a toggle in the Nuxt config. |
Update: This PR is now on top of #6864, and renamed to |
autoImports.enabled
allowing to disable auto-importimport.autoImport
allowing to disable auto-import
import.autoImport
allowing to disable auto-importimports.autoImport
allowing to disable auto-import
You probably wanted to reference to another PR here, given your comment mentions this same PR. |
Probably #6864 is the correct one |
@rvanlaak Thanks for the DI idea, but I guess it might a bit off-topic here. It would be great if you could open up a new discussion with a more detailed example/approach that you think would be useful. So we could discuss there. |
@antfu Do you mind to rebase PR? |
1697d1a
to
124de92
Compare
Done! |
imports.autoImport
allowing to disable auto-importimports.autoImport
option to disable auto-imports
β¦import
π Linked issue
fix nuxt/nuxt#14505
β Type of change
π Description
Since Nuxt uses
#imports
internally and modules would also need it, we shouldn't completely disable the transform, but instead, we could make implicit imports possible to opt-out.π Checklist