vue-facing-decorator, vue-i18n can't load local i18n bloc
Closed this issue · 7 comments
I'm currently attempting to migrate a large Vue 2 application to Vue 3. As a result, I'm utilizing the vue-facing-decorator. I appreciate the creation of this library, as it prevents the migration from becoming a complete rewrite from scratch.
In my project, I have a dependency on vue-i18n and I use localized i18n custom blocks in components to add translations for each component. I've discovered a conflict between vue-facing-decorator and vue-i18n, where local messages are not being loaded.
I've identified the cause of this issue and have published a fix. However, I would value your opinion on this matter. It might assist someone else, considering I spent five days figuring out why it wasn't working as expected.
Note: This issue seems to occur only when I define the following alias: 'vue-facing-decorator': 'vue-facing-decorator/dist/index-return-cons'.
the issue: intlify/bundle-tools#268
the fix: intlify/bundle-tools#269
@rdhainaut Just out of curiosity, what effect does removing that alias have? We haven't actually been using that alias in our migration and haven't noticed any issues, but we also aren't using vue-i18n
@rdhainaut Just out of curiosity, what effect does removing that alias have? We haven't actually been using that alias in our migration and haven't noticed any issues, but we also aren't using vue-i18n
If you remove the alias then the i18n plugin works as expected (and so local messages stored in i18n component bloc are loaded) but then other feature are broken and the official doc of vue facing decorator recommend to add that alias (see: https://facing-dev.github.io/vue-facing-decorator/#/en/compatibility/reflect-metadata/reflect-metadata)
I have created a repo with the issue here https://github.com/rdhainaut/vue3-vfd-i18n-issue (and you can try the behavior in comment the line 18 of vite.config https://github.com/rdhainaut/vue3-vfd-i18n-issue/blob/master/vite.config.ts)
Try replace your patch with Component.__o || Component.__vccOpts || Component and see if it works.
Keep the alias enabled.
Try replace your patch with
Component.__o || Component.__vccOpts || Componentand see if it works.Keep the alias enabled.
Done and it works as expected if I add "Component.__vccOpts" only
intlify/bundle-tools@767f2ba
@rdhainaut With the patch in your example repo (and the alias still present) the local translations seem to be working but I'm seeing warnings about not seeing the global "hello" key - is that expected?
@rdhainaut With the patch in your example repo (and the alias still present) the local translations seem to be working but I'm seeing warnings about not seeing the global "hello" key - is that expected?
Yes: it s the expected behaviour
By default, vue-i18n print 2 warnings when the key doesn't exist in local messages and then fallback to global messages
It s the case here
Note: Because I use 3 different methods to print 'hello', there are 6 warnings in console
Official doc: https://vue-i18n.intlify.dev/guide/essentials/local.html#i18n-component-options
@rdhainaut Thanks for all the context! It sounds like your fix in the intlify package is the way to go...is there anything else here you think would be beneficial from vue-facing-decorator's side?
I guess theoretically vue-facing-decorator could also have resolved the issue by adding a new Component.__o = Component.__vccOpts property...but that probably wouldn't make sense unless we think there are many other packages also looking for an __o property from class components?