Open typeofweb opened 6 days ago
That's interesting, thanks for the report!
The reason is that next-intl
constructs a now
value when the first component calls into i18n/request.ts
(in your case through getMessages
). This is in turn used for relative time formatting.
However, in your case (and probably many other apps), there's no need for relative time formatting.
Some potential solutions that come to my mind:
format.relativeTime(…)
is callednow
generally, let the user provide thisnow
mandatory for format.relativeTime(…)
and remove this from i18n/request.ts
It seems like these approaches all have some drawbacks, e.g. not being able to forward now
to the client side, requiring a bit more work for the user, etc.
This needs a bit further investigation. It's also still very early for PPR and dynamicIO
, will have to see how the feature moves along. However, from the current perspective it seems like next-intl
will have to adjust in some way.
Workaround
As a stopgap solution, you can put a 'use cache'
at relevant places.
E.g. in i18n/request.ts
:
import {getRequestConfig} from 'next-intl/server';
async function now() {
'use cache';
return new Date();
}
export default getRequestConfig(async () => ({
locale: 'en-US',
messages: {},
now: await now()
}));
… or in entry points (like layout.tsx
).
I just noticed that you can also add a function that provides now
and internally has a 'use cache';
. Still not ideal, but I believe a better workaround for the time being than having to decorate entry points like layout.tsx
.
Description
When
dynamicIO
is enabled, functions such asgetMessages
orgetLocale
causenext build
to fail with the following error:Verifications
Mandatory reproduction URL
https://github.com/typeofweb/repro-nextintl
Reproduction description
Steps to reproduce:
pnpm build
.getMessages
fromlayout.tsx
.pnpm build
.Expected behaviour
No errors.