async plugins with await - typescript angry
I'm curious what I'm doing wrong here. It almost seems like a nuxt TS bug. If I remove "provide" from the resolve within the IF statement the TS error disappears (but then $ketch doesn't actually exist), but if I run it as is, it works fine.
6 Replies
Hi @Josh Deltener. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Based on the information provided in the knowledge sources, I can address your question about async plugins with await in Nuxt and the TypeScript error you're encountering. This issue is related to how Nuxt handles context and async operations in plugins.
The problem you're experiencing is likely due to the way Nuxt transforms async functions in plugins. According to the Nuxt documentation on auto-imports, there are limitations on using
await before calling composables:
"you cannot use await before calling a composable, except within <script setup> blocks, within the setup function of a component declared with defineNuxtComponent, in defineNuxtPlugin or in defineNuxtRouteMiddleware, where we perform a transform to keep the synchronous context even after the await."
However, there are some known issues with this transformation, especially when it comes to try/catch statements containing await. As mentioned in the useNuxtApp documentation:
"The unjs/unctx transformation to automatically restore context seems buggy with try/catch statements containing await which ultimately needs to be solved in order to remove the requirement of the workaround suggested above."
To address your specific issue:
1. The TypeScript error you're seeing when including provide in the resolve within the IF statement is likely due to the context restoration not working correctly with the async function.
2. The fact that it works fine when you run it, despite the TypeScript error, suggests that the runtime behavior is correct, but the type inference is not catching up with the transformation.
To work around this issue, you could try the following:
1. Use nuxtApp.runWithContext after any awaits to ensure the context is properly restored.
2. If possible, restructure your plugin to avoid using await before calling composables or providing values.
3. You might also want to check if you're using the latest version of Nuxt, as some issues related to plugin typing have been addressed in recent updates, such as the one mentioned in this GitHub pull request.
If the issue persists, it might be worth reporting it as a potential bug in the Nuxt GitHub repository, as it could be related to the known limitations of the context restoration transformation.
Remember, when working with plugins in Nuxt, it's generally recommended to use composables instead of providing helpers to avoid polluting the global namespace and keep your main bundle entry small, as mentioned in the Nuxt documentation on plugins.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------<@364571742020304896> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
@TheAlexLichter am I being dumb again?
seems like TS can't infer that the thingy you return at the end won't be null
and thus says it is a signature mismatch
probably waitUntilTrue doesn't typeguard that properly?
i highly doubt it does 😛
TBH I never knew i had to be concerned with the type of an await .. i clearly need more xp in ts land!
my fav function for waiting for random junk you can't really control
