Feedback for v4

[amannn]

Let me know about your experiences with next-intl@4!

[jspm2013]

hi Jan, thanks for the beta and your work on all those updates lately to the react/next ecosystem - but i am seriously not at all able to make it run with next15. But as far as I understood it should work there... Can you please share an app router example with next15?

[jspm2013]

hi Jan, they have relaesed 15.2 two days ago, but it doesnt mention vercel/next.js#73431 to be included... :(
Do you have any communication with them about it...?

[amannn]

It was in fact included, just not prominently advertised: #1442 (comment)

[jspm2013]

ahhh thats cool - would you mind giving a short reply here when you updated your docs? 🙏

[amannn]

As mentioned in the other thread, the docs and examples have been updated to Next.js 15 now!

[jspm2013]

oh thank, you Jan!!! 💪

[frenchki]

I believe there is a bug with the typings in <NextIntlClientProvider> that makes messages still expect the old messages typings before doing the new TypeScript augmentation in v4

As a workaround, I have just done messages as unknown as AbstractIntlMessages | undefined

[amannn]

It's true that NextIntlClientProvider currently expects AbstractIntlMessages, yes. However, I'm wondering why you have to cast your messages to pass them to the prop? Do your messages not comply with AbstractIntlMessages?

Note that your typed AppConfig['Messages'] can not be used directly for the messages prop of NextIntlClientProvider. While in your case this might be true since you're passing all messages, if the developer is more selective and only passes some messages, TS would complain about missing keys.

What we could do though is expecting a deep partial of AppConfig['Messages']. I made a note about this in #1412.

Would be curious to learn more about your use case though!

[frenchki]

I found the issue that I was having. 😄 The typings will work as expected when the translation JSON does not have an array of items.

This will work:

{
  "common": {
    "test": "We are testing"
  }
}

This will not:

{
  "common": {
    "test": "We are testing",
    "listOfItems": [
      "item 1",
      "item 2"
    ]
  }
}

I was doing this as an example on the page to get an array of items rendered.

export default async function Home({ params: { locale } }: HomeProps) {
  setRequestLocale(locale)

  const t = await getTranslations()
  const messages = await getMessages({ locale })

  return (
    <ul>
      {messages.listOfItems.map((value, index) => (
        <li key={index}>{value}</li>
      ))}
    </ul>
  )
}

[amannn]

Ah yep, I see! I'd suggest to follow the array pattern as outlined in the docs, this is guaranteed to work. Future optimizations for next-intl might also not work with arrays in your messages definitions, therefore I'd encourage you to update this.

[JOsacky]

build: ./middleware.ts:2:8
build: Type error: Module '"/Users/jonathanosacky/WebstormProjects/meter-backend/node_modules/.pnpm/[email protected][email protected]_@[email protected]_@[email protected]_@playwright+tes_8522c377d6769f2abe5601dcb81264e0/node_modules/next-intl/middleware"' has no default export.
build: 
build: > 2 | import createMiddleware from 'next-intl/middleware';

After migrating to 4.0.0, I'm getting a new import error for createMiddleware. I didn't see any mention of migrating the middleware in the 4.0.0 guide so I was wondering if this was an issue in 4.0.0 or an implementation issue on my end. Congrats on the major release!

[JOsacky]

Yes looks like an edge case with certain budler config. I believe if the tsconfig moduleResolution is set to node then this happens. Try switching "moduleResolution": "node" in tsconfig

"module": "esnext",
"moduleResolution": "node",

[MiXeR54]

I have the same issue.

Module '"../node_modules/next-intl/middleware"' has no default export.ts(1192)

tsconfig:
"moduleResolution": "node",
"module": "esnext",

[JOsacky]

[{
	"resource": "/Users/jonathanosacky/WebstormProjects/meter-backend/node_modules/.pnpm/[email protected][email protected]_@[email protected]_@[email protected]_@playwright+tes_8522c377d6769f2abe5601dcb81264e0/node_modules/next-intl/middleware.d.ts",
	"owner": "typescript",
	"code": "1203",
	"severity": 8,
	"message": "Export assignment cannot be used when targeting ECMAScript modules. Consider using 'export default' or another module format instead.",
	"source": "ts",
	"startLineNumber": 4,
	"startColumn": 1,
	"endLineNumber": 4,
	"endColumn": 27,
	"modelVersionId": 1
}]

here is the full error in next-intl/middleware.d.ts

[amannn]

Thanks for the details, I was able to reproduce it with moduleResolution: 'node'! There was indeed an oversight here as part of the ESM switch.

Should be fixed as of [email protected]! 🚀

[JOsacky]

Thank you for the quick fix, confirmed the fix works in 4.0.1!

[daveycodez]

It would be awesome to have a <Trans> component similar to i18n that automatically creates JSON entries for the default language when rendered.

For example if my defaultLocale is "en" and I have:

<Trans>
    Welcome!
</Trans>

Whenever this component gets rendered in dev environment or during build, it automatically creates an entry in messages/en.json with a random key hash:

(md5 hash example)

{
    "9a843f20677a52ca79af903123147af0": "Welcome!"
}

This would enable me to easily write automatic translations using scripts, and streamlines the dev process since you can write the main copy directly in the components instead of needing to manually track keys. And manually editing JSON files is pretty un-fun

could also accept an optional tKey prop and use that as the key in the json instead of hash. But default to hash if tKey is not present.

[daveycodez]

It would also be great to have a trans() function that accepts a string or object

e.g.

<p>
    {trans("Welcome!")}
</p>

<p>
    {trans({ message: "Welcome!", tKey: "welcome" })}
</p>

[daveycodez]

Might be more clear to rename it to <Translate> and translate() though

[daveycodez]

I've been planning to make this as my own separate package that works alongside next-intl but would much prefer to have it baked in

[amannn]

There's a bit of existing discussion on this here: #456

[dsm-ostec]

After upgrading to 4.0.0 I'm getting a import error from createNavigation. I'm not sure if this is an implementation issue on my end or if there has something changed due to the esm-only build.

[sdumjahn]

After migrating my project again, the error is not there anymore

[wingsofovnia]

I am having the same problem when migrating from next-intl v3.26.5 to v4 in my nextjs v15.3.1 app-router project:

next dev --turbopack # fyi: no --turbopack - same error

node:internal/process/promises:391
    triggerUncaughtException(err, true /* fromPromise */);
    ^

Error: Cannot find module '/Users/redacted/node_modules/next/navigation' imported from /Users/redacted/node_modules/next-intl/dist/esm/production/navigation/react-client/createNavigation.js
Did you mean to import "next/navigation.js"?
    at finalizeResolution (node:internal/modules/esm/resolve:283:11)
    at moduleResolve (node:internal/modules/esm/resolve:952:10)
    at defaultResolve (node:internal/modules/esm/resolve:1188:11)
    at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:642:12)
    at #cachedDefaultResolve (node:internal/modules/esm/loader:591:25)
    at ModuleLoader.getModuleJobForRequire (node:internal/modules/esm/loader:347:53)
    at new ModuleJobSync (node:internal/modules/esm/module_job:333:34)
    at ModuleLoader.getModuleJobForRequire (node:internal/modules/esm/loader:407:11)
    at new ModuleJobSync (node:internal/modules/esm/module_job:333:34)
    at ModuleLoader.importSyncForRequire (node:internal/modules/esm/loader:320:11) {
  code: 'ERR_MODULE_NOT_FOUND',
  url: 'file:///Users/redacted/node_modules/next/navigation'
}

Node.js v20.19.0

[wingsofovnia]

@amannn I found out what is the issue and here is a reproduction https://github.com/wingsofovnia/next-intl-bug-repro-app-router:

• Up until 023769 (Browse files) I replicated my somewhat custom next-int config that failed for me when migrating to v4. It however worked flawlessly.
• I proceeded with copying over some of my permanent redirects(), see 5fef67, and it broke.
• By trial and error I figured out it wasn't redirects() per-se but @/i18n/config I imported.
• Apparently, export const intlNavigation = createNavigation(intlRouting) code (that was imported along the way) triggered the failure. Moving it to a separate file (as in the official doc tutorial) fixes the issue, see 8189e44.
• Alternatively, downgrading to npm install [email protected].

While my choice of putting things together into a single i18n/config.ts might be questionable, the fact that downgrading helps, means it is a regression. Also, separating those is rather a (suggested) convention, isn't it, so having a single i18n/config.ts isn't particularly "illegal" and should work.

Is it worth raising an issue?

[amannn]

I think this is related: vercel/next.js#77200 (comment). Currently Next.js is a bit in a weird state to be consumed by ESM-only dependencies.

Also this is related: #1669 (comment).

I hope that Next.js can clean up some bundling behavior upstream so these issues don't leak out to users. I'm unfortunately not aware of anything that next-intl could do here currently :-/.

[gkielwasser]

@amannn I noticed a few related issues and comments, and this might help others who are blocked for now.

I encountered the same problem with Next 15.5.2 and next-intl 4.3.6 when importing createNavigation:

import { createNavigation } from 'next-intl/navigation';

Some internal imports within next-intl targeting nextjs weren’t being resolved correctly.

As a temporary workaround, I added next-intl to transpilePackages in next.config.js. This allows Next.js to transpile the package, ensuring its internal paths to next are resolved properly.

[MarkMiklos]

NextIntClientProvider is mandatory for the createNavigation API, so basically I should wrap the whole app with it, right?

How does it affect the performance, because i guess it loads all the message and etc. for the whole app now, or I'm missing out on something here? If it does what is the alternative?

[amannn]

Yep, this was done in preparation for upcoming features in Next.js.

If you've previously used NextIntlClientProvider e.g. in your root layout to provide messages and you now move it slightly up in the tree, there will be no performance difference. If you don't use any messages in Client Components, you can opt-out of providing messages via messages={null}.

On a related note, providing more help with passing only a minimum amount of messages to the client side is something on the roadmap for this year (see #1) — I hope to have more to share on this in the future!

[MarkMiklos]

So basically for now the best practice is to remove all the providers that wraps the client components, and move it to the root?

[amannn]

If you have more granular providers, you can absolutely keep all those. The only requirement is that you have a provider that wraps all Client Components of your app—practically only to provide the locale. So what you can also do if you don't already have a NextIntlClientProvider in your root layout, is add a new one and set messages={null}—that way you can keep all your granular passing of messages, while providing the locale now with the new provider.