-
Notifications
You must be signed in to change notification settings - Fork 124
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
The type definition of $loading
conflicts with Buefy's one
#49
Comments
Well, there is the same issue for ElementUI if i'm right. I don't know what we're supposed to do, both of frameworks (Nuxt & Buefy) are setuping the same variable so 😬 @manniL WDYT ? The only solution could be to have the |
@kevinmarrec The problem lies even deeper. If ElementUI and Buefy both use We should think about how to properly avoid naming collisions like that. |
Is it necessary to have a plugin namespace in Vue first? |
@manniL I don't know, I guess they override Nuxt as they are Vue plugins ( |
I have this issue with Element-ui also. Are there any clarifications on this? Maybe a temporary fix? |
Sorry if we didn't find a workaround yet. UI libraries shouldn't directly non-namespaced add properties to the Vue instance interface. The issue is that these 2 UI libraries can't change this behavior without breaking changes. |
@kevinmarrec I understand, and I agree with you. Is there a way for us to make a workaround? |
@SebastianKS Ideally creating issues in the corresponding repos 🙈 |
I run into the issue with Element-ui as well. |
I believe this is not a Nuxt-ts or element-ui issue
|
@bichikim The issue is that it's a naming collision between the |
@manniL Oh i see~ in that case, fix element-ui loading at |
This error prevents the command In my case, it's conflicting with Buefy.
|
For now i added the following to my "compilerOptions": {
"skipLibCheck": true
} |
@P-de-Jong's solution works for me |
This also worked for me, however, it seems to be more of a work-around than a solution. |
We will change it to |
@manniL In fact it's already The issue is IMO 100% Buefy fault which is not extending but overriding Vue typedefs through https://github.com/buefy/buefy/blob/dev/types/index.d.ts#L10. By doing this, they force the Vue instance to always have Unless we force us to change the name from |
@kevinmarrec Whoops. Updated my statement based on the things discused in the last meeting |
since if interface NuxtAppAnyLoading extends Vue {
$loading: any
}
export interface NuxtApp extends NuxtAppAnyLoading {
$loading: NuxtLoading
isOffline: boolean
isOnline: boolean
} |
I confirmed fixed issuse with Buefy v0.8.0. |
This issue still persists with element-ui |
For Element-UI, the only work-around that got me out of the mess is to override Nuxt's $loading. I did this by creating a new type file in my app and defining an interface which extends NuxtApp type, where I defined the type of $loading as 'any': In file ~/types/nuxt.d.ts import { NuxtApp } from "@nuxt/vue-app/types/index";
export interface NuxtLoading extends NuxtApp {
$loading: any
} |
i tried
this is no error, still not working
|
Since new TS support, import { NuxtApp } from '@nuxt/types/app/index' |
Thanks @kevinmarrec |
@kevinmarrec Doesn't solve my problem :/ In file ~/types/nuxt.d.ts import { NuxtApp } from '@nuxt/types/app/index'
export interface NuxtLoading extends NuxtApp {
$loading: any
} nuxt: 2.9.2 Do I need to add nuxt.d.ts somewhere in tsconfig.json? |
@danito as a temporary bypass I just forked the @nuxt/types and edited: node_modules/@nuxt/types/app/index.d.ts:91 From:
To:
|
Has there been an issue open on ElementUI's repos about this? I'd imagine this is something they could fix although Nuxt locking down a generic global name like $loading might cause future issues. Although it's difficult to say where that line should be or not. |
For the record the new issue on ElementUI is located here: ElemeFE/element#17630 |
BTW: Is Element-UI actively maintained or should I switch to another UI-framework? No commit since 23 days seems to be strange for such a big project!? |
23 days seems indeed strange. |
Has anyone found an official workaround (that may already present in this thread) that currently works ? |
In tsconfig.json:
works for me, but hmm Maybe instead,
works, too? |
The real solution is either Nuxt or ElementUI needs to fix their namespace clashing and pick a less generic name than "loading" for root-level global stuff. But yes, either edit the ts configs as above or fork Nuxt and change NuxtApp's interface to |
Maybe it would be worth to start thinking in terms of the composition API? If Nuxt and/or ElementUI provided this stuff through a composable there would be no problem. For example, I'm relying on a custom made |
That would be ideal although legacy support for the current Vue 2 is a long term goal for the team I believe. |
Yes, that's still a problem. |
As it's a unfixable issue around the module itself, i'm closing it here. Please open an issue around Nuxt core repo (there may already be one) about changing |
oh . it is so sad。 |
Version
v2.4.0
Reproduction link
https://github.com/iwata/codesandbox-nuxt
Steps to reproduce
What is expected ?
No type checking errors
What is actually happening?
It shows this error:
Additional comments?
If you import
Buefy
looks likeplugins/buefy.ts
, it declares$loading
for Vue instance.https://github.com/buefy/buefy/blob/dev/types/index.d.ts#L10
So
NuxtApp
extends the Vue, therefore$loading
conflicts.https://github.com/nuxt/nuxt.js/blob/v2.4.0/packages/vue-app/types/index.d.ts#L73-L74
The text was updated successfully, but these errors were encountered: