Blog

Timeli.sh is a monorepo. The main customer-facing app and the admin dashboard are both Next.js, so using next-intl there is straightforward - install the package, wire up getRequestConfig, add the plugin to next.config.js, done. But there is a third app in the repo: job-processor, a Node.js background worker that runs appointment reminders, SMS notifications, and other async tasks. It is built with esbuild and has no Next.js anywhere near it.

The job-processor sends emails and SMS messages that contain translated strings. Those strings come from the same shared @timelish/i18n package that the Next.js apps use, which is built on top of next-intl. So I needed next-intl's getTranslations to work inside a plain Node.js process, bundled by esbuild, with no React renderer, no request context, and no next/headers available at runtime.

This post is about the three things that stood between me and a working build.

next-intl is designed around Next.js App Router's React Server Components model. Two things in its design cause problems the moment you step outside that environment.