feat: support js and ts extension resource formats

[kazupon]

🔗 Linked issue

close #1576
close #1448

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 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)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[pumano]

@kazupon would love if it will be merged soon and released! Thank you for that feature!

[ineshbose]

Good things come to those who wait 😉

[ineshbose]

How about a composable to help locale functions be typed?

Something like:

type LocaleFunction = (context: NuxtApp, locale: Locale) => MaybePromise<Record<string, any> | any>
export const defineI18nLocale = (p: LocaleFunction) => p

Also, maybe context: NuxtApp as a parameter could move to the last and be defaulted as context = useNuxt() (from @nuxt/kit, but depends on the context of the function)?

[kazupon]

Thank you for your review!!

How about a composable to help locale functions be typed?

Sorry, What do that compostables mean?
I could not understand that use case 😅

The functionality we will support is defined in the langDir module option, and the context and locale passed in that function are passed in the nuxt i18n module. I didn't understand the benefit of making it composable.

[ineshbose]

I may not be using the term appropriately, but just a helper/wrapper function used in JavaScript files in langDir to help ensure that the function is typed and valid. Similar to how defineNuxtConfig allowing Nuxt configurations to be typed according to NuxtSchema otherwise nuxt.config.ts could also look like:

export default {
  modules: ['@nuxtjs/i18n'],
  i18n: {}
}

But this wouldn't be an easily typed config (also without JSDoc). So with the composable, this is what I mean:

export default defineI18nLocale((context, locale) => {
  return {}
})

compared to

export default function (context, locale) => {
  // what types are context and locale??
}

Because defineI18nLocale is just a small wrapper/helper function (with no logic other than just returning the function inside - also very similar to defineNuxtPlugin) - it would at least ensure that context and locale and also the return type are valid without having to mention NuxtApp or Locale that also won't be able to used in non-typescript files.

If this is still confusing, that's fine - I can still make a separate PR for it myself immediately after this has been merged.

[pumano]

@ineshbose could you please review? I'm counting days and hours when it will be released 😅

[ineshbose]

@pumano I'm reviewing the changes continuously - but it'll be kazupon himself to decide when it's ready 🙂

[pumano]

@kazupon could you please release new version? I'm really need this feature.

[ineshbose]

It should be released on edge (just checked, doesn't seem to be there 🤔), but a tagged release may take a while.

[steel97]

@ineshbose it looks like release edge step was skipped

[kazupon]

I've just tried to release with github action
https://github.com/nuxt-modules/i18n/actions/runs/4502384367/jobs/7924323710

[tushar-compro]

Hi @kazupon ,

Is there any timeline when js/ts will be available for localization files? Or is it already there and I'm missing something? because I'm still not able to use files like en.js, es.js etc although en.json is working fine.

Regards

[kazupon]

You can conigure experimental.jsTsFormatResource: true.
docs is saying:
https://v8.i18n.nuxtjs.org/guide/lazy-load-translations

nuxt i18n is currently v8 RC, so it will be made available by default if no critical issues are reported.