fix: use generated tsconfig and virtual file augmentations

[BobbieGoede]

🔗 Linked issue

❓ 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 cleans up the virtual file augmentations as well as the tsconfig file to resemble the module started more.

I had to add a bunch of type assertions for both I18n and runtime config types, will need to look into these,

Thanks to @userquin for giving examples on how to deal with the virtual file types!

📝 Checklist

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

[kazupon]

Great work!
This approach makes sense!

I have always found it strange that the src directory contains a mixture of .ts implementation files and .d.ts type definition files, and I have wanted to refactor them at some point.

Virtual modules solve this issue, but it depends on the bundler. Since the nuxt module is a framework module system and Nuxt provides a bundling framework system, I believe the bundler dependency is not an issue.

Let's keep it up!

@userquin
Thank you for supporting!

[BobbieGoede]

Seems to be working as expected now 🤔 It's unfortunate that we now have two identical virtual file augmentations, and will have to look into the added type assertions in a future refactor. But overall this should make the module types more predictable and in line with established (but undocumented 😅) conventions among Nuxt modules.

[pkg-pr-new]

Open in Stackblitz

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

commit: 6d45160