Compatibility of now with experimental.dynamicIO in Next.js canary versions

[typeofweb]

Description

When dynamicIO is enabled, functions such as getMessages or getLocale cause next build to fail with the following error:

Error: Route "/_not-found" used new Date() instead of using performance or without explicitly calling await connection() beforehand. See more info here: https://nextjs.org/docs/messages/next-prerender-current-time

Verifications

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

Mandatory reproduction URL

https://github.com/typeofweb/repro-nextintl

Reproduction description

Steps to reproduce:

1. Run pnpm build.
2. Observe the error.
3. Remove usage of getMessages from layout.tsx.
4. Run pnpm build.
5. Observe no errors.

Expected behaviour

No errors.

[amannn]

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:

1. Construct the date only when format.relativeTime(…) is called
2. Remove a default for now generally, let the user provide this
3. Make now 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).

[amannn]

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.

[amannn]

This will be fixed in the upcoming next-intl@4! (#1536)

I've been heads-down exploring implications of dynamicIO with next-intl for the past few days, and I think I finally arrived at a reasonable solution for this case.

For users who don't use relative time formatting, there will no longer be any issues in regard to dynamicIO. For those who do, the next-intl docs will now suggest an approach that allows for granular caching in Server Components or alternatively rendering in Client Components. I think this should provide the best of both worlds.

→ Updated docs

A first beta version of next-intl@4 should be available soon, this was one of the last items on my list.

Thanks again for opening this issue!