☂️ Umbrella: List of potential features / changes for a major version

[amannn]

The big goal for the next major release is to get everything out of the way that a) makes the setup harder than necessary and b) could slow down feature development for the foreseeable future.

This is a list of ideas for API changes that we could potentially introduce in a major version:

• Maybe we could automatically forward formats to Client Components with an option to opt-out (formats={null}). Keep in mind: fix: Don't retrieve defaults for locale, now and timeZone if these options have been provided to NextIntlClientProvider #633. See previously proposed docs changes in 80332fc.
• Should nested NextIntlClientProvider inherit from each other? That would be very helpful to configure error handling as long as there's no better alternative (see Fully serializable config #611)
• Go ESM-only? This has been supported since Next.js 12. See also Pure ESM package. next.config.js might be the trickiest one, but Node.js 22 (scheduled to be recommended by Autumn '24) supports requireing ESM from CJS too. Alternatively we could consider making an exception for next-intl/plugin (ref). If we do this, we can likely also go far a faster size limit preset.
• Target more modern browsers. Currently we compile e.g. rest parameters, which have been supported by browsers since a long time. Not sure if this is a bug in @babel/preset-env, as "safari 12" results in rest params being compiled. In exchange, we can reduce bundle size. Does Next.js apply code transforms for backwards compat anyway to node_modules? See also various options in next.config.js like bundlePagesRouterDependencies.
• Use modern JSX runtime consistently
  • Babel: ['@babel/preset-react', {runtime: 'automatic'}]
  • TypeScript: "jsx": "react-jsx"
• Remove deprecated defaultTranslationValues
• Remove support for detecting src/i18n.ts
• Remove legacy navigation APIs (see feat: createNavigation #1316)
• Use const type params in createMiddleware, require TS >=5
• Mandatory locale return value in getRequestConfig
• Cookie changes: Decrease default cookie expiration to a few hours, remove resolvedOptions.localeDetection from condition in middleware (mention in changelog), add section to docs about possibility of using a longer max-age value (but you need to tell users next to your language picker)
• Type useMessages() hook using IntlMessages #1452
• Maybe Strictly typed useLocale #1377? (in case we overhaul the type registration API) Check this in combination with other types that receive a locale (e.g. routing APIs).
• Remove RequestLocaleLegacy (only an internal change)
• Maybe Type-safe arguments #410?

(remaining tasks have been moved to #1412)

No decision has been made on these so far, but if you have feedback about these points, please leave it here!

[amannn]

Adding the prefix for getPathname was also discussed in #785 (reply in thread).

[vricop]

Return typed messages from useMessages would be really nice.

Does anyone know a workaround for this?

[vricop]

Return typed messages from useMessages would be really nice.

Does anyone know a workaround for this?

I find out how to properly type safe the useMessages hook temporarily.

We can overload the function in our ./global.d.ts types like this:

import en from 'messages/en.json'

export type Messages = typeof en

declare module 'next-intl' {
  interface IntlMessages extends Messages {}
  
  function useMessages(): IntlMessages;
}

[vricop]

Return typed messages from useMessages would be really nice.
Does anyone know a workaround for this?

I find out how to properly type safe the useMessages hook temporarily.

We can overload the function in our ./global.d.ts types like this:

import en from 'messages/en.json'

export type Messages = typeof en

declare module 'next-intl' {
  interface IntlMessages extends Messages {}
  
  function useMessages(): IntlMessages;
}

⚠️🚨 DON'T DO THIS. I FIND OUT IT BREAKS t() TYPE SAFETY ⚠️🚨

After trying many things I ended using type assertion with as:

 const t = useTranslations()
 const message = useMessages() as unknown as Messages

Not ideal, but at least there's a workaround.

[amannn]

All items mentioned above have been resolved in the next-intl 4.0 beta!