Support for Next.js 15 RC and React 19 RC

[Aralf]

Description

I have taken the example code from example-app-router-next-auth that has the With i18n Routing setup; and tried to use latest Next canary (18.3.0-canary.70 at the time of writing this) with React 19 RC in order to test both that and the new React compiler.

There seems to be an issue with React 19, as the application fails to run, even without trying the React compiler.

Without turbo it shows the following error.

With turbo, instead shows this error.

I have made another branch where I have follow the documentation for Without i18n routing. This removes the [locale], navigation.ts and use of next-intl middleware on middleware.ts. With these changes the application runs perfectly fine both with/without turbo and the react compiler.

Verifications

• [X] I've verified that the problem I'm experiencing isn't covered in the docs.
• [X] I've searched for similar, existing issues on GitHub and Stack Overflow.
• [X] I've compared my app to a working example to look for differences.

Mandatory reproduction URL

https://github.com/Aralf/next-intl-react-19-compiler

Reproduction description

Steps to reproduce:

1. Run next dev with or without turbo
2. It will not work, in both cases throws different errors.
3. There is no need for trying React compiler as it already fails.
4. Change to branch without-i18n-routing
5. React compiler is already enabled on next.config.mjs
6. Run next dev with or without turbo
7. It works woks for all cases

Expected behaviour

It should work for both the With i18n routing and the Without i18n routing setups.

[amannn]

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.

[Aralf]

@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).

[heresyrj]

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

[Gawdfrey]

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

[singuerinc]

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

[zipme]

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

[amannn]

I've just upgraded two examples in https://github.com/amannn/next-intl/pull/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 https://github.com/vercel/next.js/pull/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 https://github.com/amannn/next-intl/pull/1089/commits/b7469596d953f113e6f63a57f749db341f817f68).

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

[amannn]

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 https://github.com/vercel/next.js/pull/65507#issuecomment-2128974838)

[Gawdfrey]

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!

[Aralf]

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.

[Aralf]

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

[fernandojbf]

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

[makoveckib]

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

[amannn]

@makoveckib Yep, I've written a detailed analysis about this in https://github.com/amannn/next-intl/issues/1375 and a canary release is already available with the relevant changes if someone wants to test it: https://github.com/amannn/next-intl/pull/1391.

[makoveckib]

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",

[amannn]

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.