☂️ 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.

Features that we can already introduce in 2.x in a backwards-compatible way:

• [ ] Routing enhancements
  • [x] https://github.com/amannn/next-intl/pull/1303
  • [ ] https://github.com/amannn/next-intl/pull/1316

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

• [x] Maybe we could automatically forward formats to Client Components with an option to opt-out (formats={null}). Keep in mind: https://github.com/amannn/next-intl/pull/633. See previously proposed docs changes in https://github.com/amannn/next-intl/pull/1046/commits/80332fc2a2daf66ea271617deb5abd2b3b10e46e.
• [ ] Routing enhancements
  • [ ] https://github.com/amannn/next-intl/issues/444
• [ ] Should the middleware automatically decide if a request should be handled or not (see example from docs), allowing us to remove the default matcher? (might need an option to opt-out) We'd only be able to do it for the localePrefix: 'always' case though (and only if the user doesn't want to automatically redirect /users → /en/users). Is this helpful?
• [ ] It's strongly encouraged to render NextIntlClientProvider from a Server Component, as we can automatically inherit config there. Do we need better error handling if the user renders this component from a Client Component? There are still valid use cases for this though, e.g. for unit testing / Storybook and in the Pages Router.
• [ ] Flip the default for DomainsConfig[number]['locales'] so that a domain only supports the defaultLocale by default, but other domains can be explicitly added? This might make the common case easier. If we do this, we could provide alternate links OOTB. But we need to include runtime error handling if not all locales are handled by a separate domain.
• [ ] https://github.com/amannn/next-intl/issues/611 / https://github.com/amannn/next-intl/issues/1285 ?
• [ ] 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.
• [ ] 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?
• [ ] Are there better terms than "with 18n routing" / "without i18n routing" that we could use that potentially read a bit easier in the docs and can be referred to easier? Example: i18n routing / provided locale.
• [ ] https://github.com/amannn/next-intl/issues/454 and maybe easier customization of cookies (see https://github.com/amannn/next-intl/issues/1268)
• [ ] Next.js <13 is no longer supported via next-intl, but use-intl works (see https://github.com/amannn/next-intl/issues/1282, also the comment in NextIntlClientProvider.tsx)

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 https://github.com/amannn/next-intl/discussions/785#discussioncomment-8159571.

[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.