Strict typing of global formats

[amannn]

Is your feature request related to a problem? Please describe.

Similar to how we support strict typing of messages, we could provide strict typing for formats.

Describe the solution you'd like

Allow the user to define IntlFormats to enable this.

Describe alternatives you've considered

Not providing strict formats.

[dBianchii]

Hey, I think I might be interested in implementing this. I was thinking of setting it close to their type definition for messages, like:

import en from './messages/en.json'
import formats from '~/i18/request.ts'
 
type Messages = typeof en;
 
declare global {
  // Use type safe message keys with `next-intl`
  interface IntlMessages extends Messages {}
type IntlFormats = typeof formats

}

Something quite like that. Do you think that this api could work? Then the user would only need to do this once and any changes to their format object would reflect the type here

[amannn]

If you're up for it, that would be 💯!

As far as I know, it has to be an interface in order to work. Interfaces have this special ability in TypeScript that declarations can be merged when re-declared.

Based on the implementation for the messages, I think these are the required steps:

1. Add a local type in use-intl/types that will be used for type checking within this repo:
   

   next-intl/packages/use-intl/types/index.d.ts

   Lines 1 to 3 in aa60dde

   	// This type is intended to be overridden
   	// by the consumer for optional type safety
   	declare interface IntlMessages extends Record<string, any> {}

2. Use the type were relevant:
   

   next-intl/packages/use-intl/src/react/useTranslations.tsx

   Line 24 in aa60dde

   IntlMessages,

Now, when a consumer installs the package, the IntlMessages type is not available, therefore defaulting to any. As soon as the consumer declares the type on the global namespace, this type will be picked up where relevant.

Maybe with a condition we could still ensure that only a string is accepted for a local format in case no IntlFormats are provided? That would probably be something to be researched. EDIT: Out-of-the-box, we support the date formats full, long, medium and short—maybe we could consider that as a default (including & {} to allow user-specified strings)? For number formatting there are defaults for currency and percent.

Let me know in case I can help with something! 🙌

[dBianchii]

If you're up for it, that would be 💯!

As far as I know, it has to be an interface in order to work. Interfaces have this special ability in TypeScript that declarations can be merged when re-declared.

Based on the implementation for the messages, I think these are the required steps:

1. Add a local type in use-intl/types that will be used for type checking within this repo:
   

   next-intl/packages/use-intl/types/index.d.ts

   Lines 1 to 3 in aa60dde

   	// This type is intended to be overridden
   	// by the consumer for optional type safety
   	declare interface IntlMessages extends Record<string, any> {}

2. Use the type were relevant:
   

   next-intl/packages/use-intl/src/react/useTranslations.tsx

   Line 24 in aa60dde

   IntlMessages,

Now, when a consumer installs the package, the IntlMessages type is not available, therefore defaulting to any. As soon as the consumer declares the type on the global namespace, this type will be picked up where relevant.

Maybe with a condition we could still ensure that only a string is accepted for a local format in case no IntlFormats are provided? That would probably be something to be researched. EDIT: Out-of-the-box, we support the date formats full, long, medium and short—maybe we could consider that as a default (including & {} to allow user-specified strings)? For number formatting there are defaults for currency and percent.

Let me know in case I can help with something! 🙌

Thanks. Will look into it when I have some free time.