feat: virtual messages HMR for vite

[BobbieGoede]

I'm slowly learning more about HMR and have been working on something similar for nuxt-i18n nuxt-modules/i18n#3363

This is a starting point for HMR without reloading the page, so translations can be changed while app state is preserved.

This PR is incomplete:

• It assumes the Vue instance is found on an element with #app
• This overwrites locale messages with those exported by @intlify/unplugin-vue-i18n/messages, if users are merging other messages with those exported by the virtual bundle (e.g. merging objects during creation of the i18n instance) these will be lost on change.
• Untested using webpack, I'm assuming it does not work the same there without additional changes.

[kazupon]

Good job!
Look good too me for your draft PR.
Let's keep going!

[BobbieGoede]

I couldn't figure out how to add support for this for webpack, so it's vite only now.

Since this functionality will overwrite all (global) messages with those from the merged virtual bundle, and since the way I retrieve the vue-i18n instance probably won't work in all projects (using #app to find vue instance), this functionality is disabled by default.

It can be enabled by passing the hmr: true option.

[kazupon]

I couldn't figure out how to add support for this for webpack, so it's vite only now.

I agree, that's enough for now.

vue-i18n instance probably won't work in all projects (using #app to find vue instance), this functionality is disabled by default.

It might be a good idea to add an option to unplugin-vue-i18n that specifies the app root.
This would be a manual, allowing you to support HMR.

[BobbieGoede]

@kazupon
I have added and option to configure the selector used appRootContainer, it defaults to '#app'.

I have also changed the HMR code so that it falls back to reloading the page if the app root instance is not found while also logging an error on the dev server.

[BobbieGoede]

The feature is now enabled by default, since it falls back to the original behavior if it fails it should work well for most projects.

My only concern is for projects that merge the messages object at creation:

import messages from '@intlify/unplugin-vue-i18n/messages'

const i18n = createI18n({
  messages: {
    en: {
       ...messages.en,
       keyLostOnHMR: 'foo',
    },
  },
})

As any additional keys there would be lost on HMR, though I'm not sure if this is a common pattern 🤔 In such cases HMR would have to be disabled.

[kazupon]

As any additional keys there would be lost on HMR, though I'm not sure if this is a common pattern 🤔 In such cases HMR would have to be disabled.

When developing, it may be a good idea to have the vue-i18n side expose an interface dedicated to HMR and work with unplugin-vue-i18n.

In the case of Vue, it seems that globalThis is exposed as a dedicated interface to support HMR for components.

https://github.com/vuejs/core/blob/604d08760ee5b01772bc33cefd89ebdca9bb1b82/packages/runtime-core/src/hmr.ts#L28-L39

I think that you can handle all messages using a similar approach for the messages (resources) of vue-i18n.

[BobbieGoede]

When developing, it may be a good idea to have the vue-i18n side expose an interface dedicated to HMR and work with unplugin-vue-i18n.

In the case of Vue, it seems that globalThis is exposed as a dedicated interface to support HMR for components.
I think that you can handle all messages using a similar approach for the messages (resources) of vue-i18n.

I'll look into adding something like it to vue-i18n, at the very least it would make it easier to get the vue-i18n instance without needing to access the app root.

I'm not sure if this would make it possible to prevent losing the additional message keys as described in my previous comment 🤔 At least I don't see a way without additional changes.