Not getting HMR to work with Vite, Vue3 and Pinia

[christianhengst]

Hi there!

I'm switching from Vuex to Pinia but having issues with "Hot Module Replacement". When changing the state in a store it is not hot updated in the component that is using the store.

I'm using single file components with the "Options API" and tried different approaches with ...mapState() and setup() with no effect.

I've created a basic repository that demonstrates the issue: https://github.com/christianhengst/vue-vite-pinia-hmr

How to reproduce

1. Clone repository and npm i
2. Run npm run dev
3. Change data counterFromComponentData in App.vue
4. Save file
5. See updated data in your browser
6. Change state counter in stores/counter.js
7. Save file
8. Nothing is updated hot. After reloading the entire page the new state is visible.

Do I get something basically wrong or is there an issue with either Vite or Pinia?

Thanks for your help!

[denglouhen]

Anybody has the idea?

[bhishekprajapati]

Facing same issue! Changes in a pinia store are not reflecting automatically but they're working fine if I manually reload the vite dev server.
Any solutions?

[kossa]

I have the same issue any solution?

[wouter-muller]

I am experiencing the same issue. All parts of my Vue/vite app get reloaded automatically on save, only when i change something in a Pinia store, it is not picked up.

[daniel-n-dream]

Experiencing the same issue, I have tried what is written in https://pinia.vuejs.org/cookbook/hot-module-replacement.html#hmr-hot-module-replacement (Using Vite 3.2) but that didn't help and made things even worse.
With that change it doesn't rerun the store action or any watcher that depends on the store anymore.

[olinoles]

Just adding on to this - I'm getting this issue when trying to use a store in a component
ReferenceError: Cannot access 'DashboardView' before initialization at index.ts:28:20 with index.ts being Vue router.

and [hmr] Failed to reload /src/features/Dashboard/DashboardView.vue. This could be due to syntax errors or importing non-existent modules. (see errors above)

I've isolated this down to using any useStore() in a component.

Vue 3.2.41
Vite 3.2.3
Pinia 2.0.23

[bhishekprajapati]

Share code snippet [index.ts:28:20]

[pegiadise]

You can make your route component an async one (() => import('@/views/DashboardView.vue')) and such errors go away. The caveat is that a new chunk is generated and you might not want that.

[jtilford]

I've noticed this behavior with Pinia on a few projects using Vue 3, Typescript, and Quasar 2 (2.10.2 right now). I also tried this solution from Pinia and have not had Vite HMR picking up state changes made in code. Definitely frustrating, and I'll be watching for any discussion on this.

After looking into this a bit further, this answer from StackOverflow cross-references #843 which states in the comment by @posva on May 13th:

Yes, the idea is that adding new state should not reset the other values of the state so existing state values are always preserved. This also means that you can change a value, comment the line and save (this removes the state property) then un comment and save again.

In short, it appears to be intended functionality that updating the state data in the code does not update state in the browser, but for Vite projects you'll still want to add acceptHMRUpdate as per the docs.

[denglouhen]

Right, saving it directly will not change the value on the page. But as it mentioned, comment the line and save, then change, un comment and save, the page changes. Effective but inconvenient.

[william-lindner]

I had to solve this in a project I was working on, and I'll admit finding the answer required me to deduce the root cause in the code rather than finding it somewhere tucked in comments on a thread. To keep someone else from having this issue I'll give as extensive an answer as possible here. If you're having this issue I hope this finds you!

I'm going to break down the example repo provided by the OP: https://github.com/christianhengst/vue-vite-pinia-hmr.

The entry point for the application is the src/main.js file.

import { createApp } from 'vue';
import { createPinia } from 'pinia';
import App from './App.vue';

const app = createApp(App);

app.use(createPinia());

app.mount('#app');

In this file the App.vue component is imported, and it is used to create the application. Within the App it imports a Pinia store.

import { useStore } from './stores/counter';

Because this store, in the context of the component, requires Pinia the import needs to occur after the application has been designed to use pinia createPinia(). Why? Because Pinia is calling getActivePinia() to define the stores against the application.

import { defineStore, acceptHMRUpdate } from 'pinia'

export const useStore = defineStore('counter', {})

That defineStore is going to do a bunch of stuff that will feel like magic, but it requires a specific timing of execution. It runs when this file is first imported. I'll explain why that matters here in a bit.

Sometimes, and even in this thread you'll see a recommendation to lazy load the component. This works, but why? Because the file is not imported directly, so it does not execute it's own imports right away. That's really all this is about. It's just timing of when you use what dependency, and once defineStore is called if you want to use that store it is going to look for active Pinia instances.

In more elaborate occurrences of this issue you'll see it when you try and use stores outside of components, like in route guards, so a good rule of thumb you can follow is to always async import your routes. This generally solves the issue by enforcing a code execution sequence that will work harmoniously with Pinia.

You could also use wrapper functions and create reference to the store that gets defined later. Honestly, I won't go into how to do this as I think the best solution really is to async load your route components. Hope this helps!

[GianpaoloPascasi]

What do you mean with

async import your routes

Do you mean importing the components lazily in the createRouter function or something else?
Thanks 😄

PS
I am getting the same problem but the Reference error is happening in a class-only file which is not touched at all by the store... very strange 😞
Removing the acceptHMRUpdate gives back auto-refresh atleast...

[william-lindner]

Yup! Lazy loading the routes is exactly what I’m referring to.Regards,WilliamOn Jun 16, 2023, at 6:16 AM, Gianpaolo Pascasi ***@***.***> wrote: What do you mean by "async import your routes"? Do you mean importing the components lazily in the createRouter function or something else? Thanks 😄 —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[benja2111]

Pour ceux et celle qui ont le problème des magasins qui ne se mettent pas à jour, j'ai la solution !!

Voici le lien de la documentation officiel Pinia qui répond à ce problème : https://pinia.vuejs.org/cookbook/hot-module-replacement.html

[GianpaoloPascasi]

I think that almost everybody here has been using this and it is not working... for me atleast ;)

[kossa]

Any solution for this?

[GianpaoloPascasi]

Any solution for this?

The problem for me was the injection of other stores. Specifically i had them already "registered" in some pinia plugins, and i wrongly redefined them in the state of the store presenting the problem. Try to check it.