feat: experimental vue-i18n and messages type generation

[BobbieGoede]

🔗 Linked issue

• $t() autocomplete support #1753
• Enable type checking from vue-i18n #2591

❓ Type of change

• 📖 Documentation (updates to the documentation, readme or JSdoc annotations)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

This is a different, improved approach compared to BobbieGoede#50, that PR reimplemented the loading of configs and messages while this PR reuses the existing logic.

(Same demo video as BobbieGoede#50 as this should be functionally the same)

Code_2024-07-17_14-54-20.mp4

📝 Checklist

• I have linked an issue or discussion.
• I have added tests (if possible).
• I have updated the documentation accordingly.

[pkg-pr-new]

Open in Stackblitz

pnpm add https://pkg.pr.new/@nuxtjs/i18n@3151

commit: ca91f96

[kazupon]

I will leave a comment on the points that I am concerned about.

I integrated all the locale messages when I implemented i18n support first time for h3.
I noticed that all the locale messages are unnecessary on the server side, affecting performance.
Since this is experimental, I think this implementation is fine, but at some point, I think a mechanism that allows locale messages to be loaded only on the server side will be necessary.

[BobbieGoede]

Hmm I'm not entirely sure what you mean 🤔 Do you mean a mechanism to load a part/subset of messages?

I haven't checked if this does anything to a project production build, this should only be used in development so I should probably disable this functionality if not in dev mode.

[BobbieGoede]

After looking into it, it looked like it was being included in production too 😅 Now this functionality should only be enabled (if configured) during development, this still has performance impact but not after building.

[BobbieGoede]

I have added some options, the configuration now accepts false | 'default' | 'all':

• false - disables type generation
• 'default' - generate types based on configured defaultLocale
• 'all' - generate types based on all configured locales

This way users can decide to only generate types using the defaultLocale resources, which prevents loading all locales unnecessarily.

[kazupon]

@BobbieGoede
Excellent work! 💯

I've wanted to implement a type generation like your PR, and I'm so happy you're supporting it!
Let's keep going!