-
Notifications
You must be signed in to change notification settings - Fork 254
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
Adding a base path to vite.config.js host module in vue3-demo-esm-expose-store pinia store sharing doesn't work #542
Comments
Found a workaround I'll put here for future reference, if someone gets the same error, but however is not suitable for production environment
Can the usage of window.location.href in the "wrapShareScope" function be a fix on the library? |
I have the same problem, any fixes for the problem? |
Hello, I'm encountering a problem when specifying a relative path inside base: "/test". Is there an official solution? |
It appears that the issue lies in the order of module loading. As seen in the screenshot, the defineStore of the Pinia store module from the host app (the app from which the Pinia module is exposed) is loaded before the createPinia call of the local app (the app that uses the exposed Pinia module). Therefore, there should be a way to specify the exact order of loading modules while in development mode. This error only occurs in development mode. |
It seems like the order doesn't matter. In the production build, the order is the same. However, when the local app is in development mode (but the host is in production), the getCurrentInstance call on the side of the local app returns nothing inside of the useStore function of Pinia's internal code. But in production mode, everything works fine. By the way, the error occurred when the host app was running in production mode (using Vite preview), but the local app was running in development mode. However, when both sides are in production mode, there are no errors. |
I figure it out. The Pinia module loads twice and rewrites some of its own internal state. You can investigate in the following steps: You need mainApp and remoteApp. MainApp exposes some stores with a default store - you run it through But remoteApp, you run through the dev way - just In that case, inside main.ts of remoteApp, it will be something like this.
That code will trigger first loading of local dependency . It can be seen inside the Nework tab - the name of file will something like this : Secondly, App.vue will be mounted, and the code inside of which will be something like this
As you can see there are That module will be imported second time through vite-module-federation plugin , because the generated code of useAuthStore will something like this :
importShared will do some magic , but it totally ignores already imported dependency importShared will import pinia again from file
and secondly rewrites pinia module internals . To prove that, you can go to remoteApp/node_modules/pinia/dist/pinia.mjs and at the top of the file, write code like this
And print it also in defineStore and useStore functions- you will see , that the tag will be different in some cases. So, to solve that ( at least temporary ) you can explicitly export the entire pinia module from mainApp
And at remoteApp import it like this:
|
Versions
Reproduction
Adding a base path to vite.config.js, the pinia store sharing doesnt' work.
To reproduce the issue you can start from "vue3-demo-esm-expose-store" demo and add the following property:
base: "/test",
in config object defined here (e.g. line 28):
https://github.com/originjs/vite-plugin-federation/blob/main/packages/examples/vue3-demo-esm-expose-store/host/vite.config.ts
The host app will run with the specified base path but the store initialization will fail with the following error:
Uncaught Error: [🍍]: "getActivePinia()" was called but there was no active Pinia. Are you trying to use a store before calling "app.use(pinia)"?
The text was updated successfully, but these errors were encountered: