Open lunarchives opened 1 month ago
Hi @lunarchives! 👋
It looks like you provided an invalid or unsupported reproduction URL. Do not use any service other than Codepen, jsFiddle, StackBlitz, Codesandbox, and GitHub. Make sure the URL you provided is correct and reachable. You can test it by visiting it in a private tab, another device, etc. Please edit your original post above and provide a valid reproduction URL as explained.
Without a proper reproduction, your issue will have to get closed.
Thank you for your collaboration. 👏
The problem happens with webpack as well
What happened?
We are developing a standalone component library for our application that is effectively wrapper components around quasar components which will be used in our set of applications.
What we have discovered is that when Vite is bundling quasar into the library's output build artifacts, there are files that the quasar library uses to track internal caches of "portal" objects so that
v-close-popup
can look through said cache and close a given portal.However, because the caches are not designed in a way to come from a separate package, it seems that module resolution across the component library and the app using the library end up with different caches when resolving the paths of these files. Specifically, the in-memory cache used here named
portalProxyList
https://github.com/quasarframework/quasar/blob/dev/ui/src/utils/private.portal/portal.js#L3Externalizing quasar in our vite config doesn't resolve the issue so we are at loss for what we could do on our end
Our vite.config.js
What did you expect to happen?
We'd expect the
v-close-popup
to still work if built from a separate wrapping libraryReproduction URL
https://na.com
How to reproduce?
v-close-popup
directive to one of the q-dialog's buttonsFlavour
Vue CLI Plugin (vue-cli-plugin-quasar)
Areas
Directives (quasar)
Platforms/Browsers
Chrome
Quasar info output
No response
Relevant log output
No response
Additional context
No response