NextIntlClientProvider SSR wrapper triggers Couldn't-find-config-file on every render in Next 16.2.4 + Turbopack production #2340

pulse-ventures · 2026-05-27T12:51:05Z

pulse-ventures
May 27, 2026

Environment

next-intl: 4.12.0
next: 16.2.4 (stable Turbopack production build)
Node: 22.x (Vercel runtime)
Runtime: Vercel production deploy
Single-locale app (en-GB), no [locale] segment, locale + messages hardcoded

Symptom

Every server render returns HTTP 500 with the runtime error:

Error: Couldn't find next-intl config file. Please follow the instructions at https://next-intl.dev/docs/getting-started/app-router
    at .next/server/chunks/ssr/<hash>_next-intl_dist_esm_production_server_react-server_getConfig_<hash>.js:3:7454

Build status is Ready — the throw is purely at request time. Local pnpm dev and pnpm build both succeed.

Reproduction

next.config.ts:

import createNextIntlPlugin from 'next-intl/plugin';
import type { NextConfig } from 'next';

const config: NextConfig = { /* any valid config */ };
const withNextIntl = createNextIntlPlugin('./src/i18n/request.ts');
export default withNextIntl(config);

src/i18n/request.ts:

import { getRequestConfig } from 'next-intl/server';

export default getRequestConfig(async () => ({
  locale: 'en-GB',
  messages: (await import('../../messages/en-GB.json')).default
}));

src/app/layout.tsx:

import { NextIntlClientProvider } from 'next-intl';
import { getLocale, getMessages } from 'next-intl/server';

export default async function RootLayout({ children }) {
  const locale = await getLocale();
  const messages = await getMessages();
  return (
    <html lang={locale}>
      <body>
        <NextIntlClientProvider locale={locale} messages={messages}>
          {children}
        </NextIntlClientProvider>
      </body>
    </html>
  );
}

Deploy to Vercel with next build (Turbopack, the Next 16 default). Visit /. → HTTP 500.

Root cause analysis

The Turbopack alias next-intl/config set by createNextIntlPlugin() does not bind to the production server bundle. Tried all of the following without effect (chunk hash changed but the throw persisted):

Setting nextConfig.turbopack.resolveAlias['next-intl/config'] manually
Setting nextConfig.experimental.turbo.resolveAlias['next-intl/config'] manually
Both of the above simultaneously
Removing my user-set experimental.turbo entirely (the plugin's slot-detection check is i() && !t?.experimental?.turbo)

The fallback module at next-intl/dist/esm/production/config.js always wins:

function t(){throw new Error("Couldn't find next-intl config file...")}
export{t as default};

Looking at NextIntlClientProviderServer.js (the SSR wrapper Next renders on the server when a client NextIntlClientProvider is used inside an async server layout):

import getConfigNow from "../server/react-server/getConfigNow.js";
import getFormats from "../server/react-server/getFormats.js";
import getTimeZone from "../server/react-server/getTimeZone.js";
import getMessages from "../server/react-server/getMessages.js";
import getLocale from "../server/react-server/getLocale.js";

async function i({formats, locale, messages, now, timeZone, ...rest}) {
  return jsx(Provider, {
    formats:  void 0===formats  ? await getFormats()    : formats,
    locale:   locale  ?? await getLocale(),
    messages: void 0===messages ? await getMessages()   : messages,
    now:      now     ?? await getConfigNow(),
    timeZone: timeZone ?? await getTimeZone(),
    ...rest
  });
}

All five fallbacks (getFormats, getLocale, getMessages, getConfigNow, getTimeZone) call getConfig() internally, which loads next-intl/config → throw-stub.

In the repro above, only locale and messages are passed, so getFormats() / getConfigNow() / getTimeZone() still fire and all 500.

Workaround

Pass every prop the SSR wrapper falls back on:

import enGBMessages from '../../messages/en-GB.json';

const locale = 'en-GB';
const messages = enGBMessages;
const now = new Date();
const timeZone = 'Europe/London';
const formats = {};

return (
  <NextIntlClientProvider
    locale={locale}
    messages={messages}
    now={now}
    timeZone={timeZone}
    formats={formats}
  >
    {children}
  </NextIntlClientProvider>
);

After this, the home page renders to HTTP 200. Server-side getTranslations() / getLocale() / getMessages() calls in OTHER routes still hit the same broken alias path and 500 — they need the same prop-passing or the underlying alias issue to be fixed.

Suggested fixes

Investigate why the Turbopack alias doesn't bind in Next 16.2.4 production. The plugin source's i() && !t?.experimental?.turbo slot-detection routes correctly to nextConfig.turbopack.resolveAlias for Next ≥ 15.3, but the resulting alias appears not to apply to the server bundle. Could be a Turbopack regression or a chunking interaction with next-intl's pre-bundled react-server_getConfig module.
Document the SSR prop-fallback surface more loudly. The current <NextIntlClientProvider> docs imply only locale + messages are needed; the server wrapper's hidden calls to getFormats / getConfigNow / getTimeZone are surprising and turn a misconfigured alias into a full production outage.
Make the fallback throw-stub more helpful — point at the relevant Turbopack alias diagnostic, not just the generic "follow getting-started" link. The error stack lands inside a content-hashed chunk and is currently very hard to map back to root cause.

Surrounding context

Documented in a 7-PR debugging cycle for an internal DruOps app. Happy to share full logs / chunk inspect URLs / Vercel deployment IDs privately if useful.

amannn · 2026-05-28T12:07:15Z

amannn
May 28, 2026
Maintainer

Moving to a discussion since no reproduction was provided and this appears to be a usage question. Please be sure to check working examples.

0 replies

Navigation Menu

Uh oh!

NextIntlClientProvider SSR wrapper triggers Couldn't-find-config-file on every render in Next 16.2.4 + Turbopack production #2340

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Uh oh!

NextIntlClientProvider SSR wrapper triggers Couldn't-find-config-file on every render in Next 16.2.4 + Turbopack production #2340

Uh oh!

pulse-ventures May 27, 2026

Environment

Symptom

Reproduction

Root cause analysis

Workaround

Suggested fixes

Surrounding context

Replies: 1 comment

Uh oh!

amannn May 28, 2026 Maintainer

pulse-ventures
May 27, 2026

amannn
May 28, 2026
Maintainer