-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bad component types since nuxt v3.11.0
#26311
Comments
This is likely the change to |
It works like a charm with But I have a feeling I'm missing a great feature. Do you think I need to investigate more into the way I'm importing components in |
Hey! 👋 We're also facing the same issue on our end, and indeed setting There's one situation where we do not have access to the Nuxt configuration to set this My wondering is more about the change itself, why we changed this property from I get that, but it seems that it not only impacts VSCode but also typechecking through |
This is a fair point and I might consider reversing this change for the benefit of third party tooling until we have a better way to get Volar’s plugin into the tsconfig. |
Here's a PR that reverts to the old (v3.10.x) behaviour. #26607 |
I would argue that the issue is still there, even after merging #26607. I'll copy/paste what I shared there (I believe it's been overlooked before merging the PR). For what it's worth, our typechecking fails even though we're using the nuxi typecheck command. I've created the following minimal reproduction: stackblitz.com/edit/nuxt-starter-vvj2wc. It's a mono-repository with one application and two modules. One module exposes a HelloWorld component via its package.json exports property. I'm not exposing the component through the addComponent function as I don't want it to be available through #imports. Note that both modules are identical. They both rely on @nuxt/module-builder to generate the types and prepare everything. I'm not relying on nuxi prepare playground here as there is no playground. Still, the typechecking steps fail on the consumer app, but also on the consumer module (module-2). While there is a way to force the shim generation on the application (and thus silence the issue), there is no such mechanism in the modules. I guess my underlying question is "why does the typechecking fail even though we're using nuxi typecheck and thus vue-tsc under the hood?". |
@antoinerey That does sound like a different matter if it's reproducible with type-checking only. Let me reopen the linked issue. |
Environment
Darwin
v21.6.2
3.11.0
3.10.1
2.9.4
pnpm@8.15.4
-
app
,css
,devtools
,experimental
,googleFonts
,i18n
,image
,modules
,nitro
,pinia
,primevue
,runtimeConfig
,tailwindcss
,typescript
,vite
@nuxtjs/tailwindcss@6.11.4
,@nuxt/test-utils/module@3.12.0
,nuxt-primevue@0.3.1
,@nuxtjs/i18n@8.2.0
,@nuxt/image@1.4.0
,@nuxtjs/google-fonts@3.2.0
,@aksharahegde/nuxt-glow@1.1.2
,@pinia/nuxt@0.5.1
-
Reproduction
You can reproduce the issue with my repo on this PR : antoinezanardi/werewolves-assistant-web-next#260
Describe the bug
When I tried to update to the latest version of nuxt
v3.11.0
, I have encountered an issue which is, I believe, related to components generated types.When I try to lint the project (with
pnpm run lint:fix
), it warns me that some components I'm using in dynamic imports are of typeany
, even if the application is perfectly building.Here is an example of the issue in a vue component :
But this issue doesn't show up only in
eslint
, but even instryker-js
(a mutation tests runner). It can't resolve any of the components with the message below :Apart of these tools, the
vitest
can run all tests without errors and the app is starting fine… All of these were working inv3.10.0
of nuxt.Is it maybe a problem with the way I'm importing the components in the
vue
andtests
files ? I tried to resolve them from the#components
path, same issue. Maybe I need to add something in thetsconfig.json
file for correct type resolving ?Thanks a lot for your help ❤️
Additional context
No response
Logs
No response
Tasks
The text was updated successfully, but these errors were encountered: