Hmm, that's interesting. The Next.js 15 release is scheduled for next week as far as I know, maybe worth waiting until then. It might be that they're still ironing out some details.

Once Next.js 15 is out, I'll open a PR to update all examples and will make sure everything works as expected.

@amannn I see, thanks.

Just as and added note, this morning I tried with my company app (where I first faced this issue) and tried the setup without i18n routing. It did work with Webpack but once I tried with Turbopack it threw the same error described above.

The app uses some other dependencies than the reproduction provided here: shadcn ui (Tailwind + Radix) and Authjs v5 beta are the only difference on the frontend part (it has some server side dependencies that I believe shouldn't affect anything with react).

can confirm this issue.
reproduced the same error on my project.

Able to reproduce it here as well.
As mentioned by @amannn, probably worth waiting until next 15 is launched this week until further investigation.

Hi, I just tried to update to Next.js 15 RC and it crashes with:

 ⨯ ../src/shared/lib/router-context.shared-runtime.ts (4:8) @ <unknown>
 ⨯ react__WEBPACK_IMPORTED_MODULE_0__.createContext is not a function
  2 | import type { NextRouter } from './router/router'
  3 |
> 4 | export const RouterContext = React.createContext<NextRouter | null>(null)
    |        ^
  5 |
  6 | if (process.env.NODE_ENV !== 'production') {
  7 |   RouterContext.displayName = 'RouterContext'
 ⚠ ./node_modules/next-intl/dist/esm/navigation/shared/BaseLink.js

This is the error I got:

./node_modules/.pnpm/next-intl@3.11.3_next@15.0.0-rc.0_react@19.0.0-rc-4c2e457c7c-20240522/node_modules/next-intl/dist/esm/navigation/shared/BaseLink.js
Attempted import error: 'useState' is not exported from 'react' (imported as 'i').

Import trace for requested module:
./node_modules/.pnpm/next-intl@3.11.3_next@15.0.0-rc.0_react@19.0.0-rc-4c2e457c7c-20240522/node_modules/next-intl/dist/esm/navigation/shared/BaseLink.js
./node_modules/.pnpm/next-intl@3.11.3_next@15.0.0-rc.0_react@19.0.0-rc-4c2e457c7c-20240522/node_modules/next-intl/dist/esm/navigation/react-server/ServerLink.js
./node_modules/.pnpm/next-intl@3.11.3_next@15.0.0-rc.0_react@19.0.0-rc-4c2e457c7c-20240522/node_modules/next-intl/dist/esm/navigation/react-server/createSharedPathnamesNavigation.js
./node_modules/.pnpm/next-intl@3.11.3_next@15.0.0-rc.0_react@19.0.0-rc-4c2e457c7c-20240522/node_modules/next-intl/dist/esm/navigation.react-server.js

I've just upgraded two examples in #1089 to Next.js 15 RC and React 19 RC. Generally this seems to work, but it looks like the issue you are seeing comes from vercel/next.js#65424.

Currently in the docs we suggest to import i18n config from ./navigation into the middleware, where also navigation APIs are defined. These navigation APIs import from next/link in turn, which results in the errors you're seeing.

For the time being you can fix this by making sure you're not importing anything from the navigation module into the middleware (see b746959).

I've asked the Next.js team for clarification if we should adjust the docs here.

Side note for those living on the bleeding edge: The test suite from next-intl discovered that serving sitemaps might be broken in Next.js 15 RC (see vercel/next.js#65507 (comment))

I've just upgraded two examples in #1089 to Next.js 15 RC and React 19 RC. Generally this seems to work, but it looks like the issue you are seeing comes from vercel/next.js#65424.

Currently in the docs we suggest to import i18n config from ./navigation into the middleware, where also navigation APIs are defined. These navigation APIs import from next/link in turn, which results in the errors you're seeing.

For the time being you can fix this by making sure you're not importing anything from the navigation module into the middleware (see b746959).

I've asked the Next.js team for clarification if we should adjust the docs here.

Cheers, moved them to a separate file for now, works excellently!

I've just upgraded two examples in #1089 to Next.js 15 RC and React 19 RC. Generally this seems to work, but it looks like the issue you are seeing comes from vercel/next.js#65424.

Currently in the docs we suggest to import i18n config from ./navigation into the middleware, where also navigation APIs are defined. These navigation APIs import from next/link in turn, which results in the errors you're seeing.

For the time being you can fix this by making sure you're not importing anything from the navigation module into the middleware (see b746959).

I've asked the Next.js team for clarification if we should adjust the docs here.

Thanks, that is clearly the issue. I have made the change on my reproduction with i18n navigation and it works.

Funny enough, I checked on my company app and noticed that in there I had already separated in two files the locales configuration and the navigation, and never imported navigation to the middleware. So it shouldn't have failed....unless the issue is somewhere else.

Well, turns out Auth.js v5 has the same issue. My reproduction uses v4 as that is the same from next-intl examples. I tested to upgrade to v5 and voilà, again the same error. I suppose I will have to open an issue on next-auth now 😅

Thanks again @amannn for finding the root of the issue.

I've been pointed out here latest Next canary includes this fix that resolves all these issues caused by vercel/next.js#65424
I've tested it on the reproduction and sure enough no more issues.

I'm using getPathname on middleware to translate some routes.

Since getPathname is exported by next-intl/navigation would be nice to have something that work only on SSR (middleware and API routes).

Breaking change in [v15.0.0-canary.171]
change : (https://github.com/vercel/next.js/releases/tag/v15.0.0-canary.171)

@makoveckib Yep, I've written a detailed analysis about this in #1375 and a canary release is already available with the relevant changes if someone wants to test it: #1391.

sill getting warnings: In route /[locale] a header property was accessed directly with headers().get('X-NEXT-INTL-LOCALE'). headers() should be awaited before using its value. Learn more: https://nextjs.org/docs/messages/sync-dynamic-apis

"next-intl": "^3.21.0-canary.0",
"next": "^15.0.0-canary.176",

There’s some minimal migration necessary if you want to get rid of the warnings, please refer to the linked PRs in the release PR.

I just gave Next.js 15 RC 2 a shot, and while some things have improved, it seems like there is still a bug on their end: vercel/next.js#69000 (comment). So be careful if you decide to upgrade to it.

Apart from that, be careful when running the codemod for transforming pages that access params and searchParams. I noticed the codemod transforms pages to async when they use hooks like useTranslations—this will break them.

Before:

export default function Page(props) {
  const searchParams = props.searchParams;
  const t = useTranslations('Page')

  // ...
}

Broken after codemod:

export default async function Page(props) {
  const searchParams = await props.searchParams;
  const t = useTranslations('Page')

  // ...
}

Fixed:

import {use} from 'react';

// (no async)
export default function Page(props) {
  const searchParams = use(props.searchParams);
  const t = useTranslations('Page')

  // ...
}

See also the notes in vercel/next.js#68812. The recently released eslint-plugin-react-hooks@5 will also warn for this.

Thanks for your efforts, @amannn? If we want to make the switch, should we use the latest canary on npm 0.0.0-canary-0ea6000 or 3.22.0-canary.1 or how do we install it?

@wottpal Yep, that's the latest one! If you install next-intl@canary that should always give you the most recent one.

Regarding 3.22.0-canary.1: That's a slightly outdated one, I had to adapt the canary publishing process due to some problems with Lerna recently which resulted in a new versioning scheme.

Ty! Got everything running smoothly on v15 🚀

Update: I'll wait with updating docs and examples for Next.js 15 for the time being since there's a critical bug in Next.js 15 that affects multilingual apps that use i18n routing.

However, I've added a separate PR that merely bumps the peer dependency: #1443. If you don't use i18n routing or don't rely on alternate links, you can consider updating already.

hi @amannn! Thanks for your great job on all this stuff and a question on your last mention above, regarding "...there's a critical bug in Next.js 15...":

Are the docs updated now, or are we still waiting for the solution on this bug?

Or more precise :)
...is it suggested to still wait for upgrading when I need to use i18n routing, or is it now possible to upgrade to 3.22 using the current docs, so that it will work without errors when implemented as described in the current docs?

next-intl can surely be updated to the latest version, I only found that Next.js 15 has a bug with alternate links (see above).

Additionally, I found this one the other day: vercel/next.js#71623. That’s not really related to next-intl though, rather a general bug and might not affect your app.

I’ll update the examples and docs in this repo once the bug with alternate links is fixed.