Use next-intl as package in turborepo monorepo

[naquiroz]

Is your feature request related to a problem? Please describe.

I'm trying to have the same config and implementation of next-intl across diferent apps inside a turborepo monorepo. The issue relies on the path of the request.ts since I havent been able to manage for it to be found by the path resolution.

Describe the solution you'd like

I would like to have a package of turborepo like @repo/internationalization where all the features and translations are stored. The most critical file is the request.ts. With that fixed, one could import the withNextInl from this package.

Describe alternatives you've considered

I've considered alterning the settings of the repo, changing the path, none of those worked.

[amannn]

You can customize the path to request.ts, maybe something like ../internationalization/request.ts could work?

I'll move this to a discussion since it seems to be a usage question.

[pericleschrstn]

I used the relative path to 'request.ts' and got it running fine.

Can you show me?

[johnschult]

I can probably put together a demo app next week.

[pericleschrstn]

Thanks, I think it will help me

[samblongchamps]

@naquiroz Any update on this? @johnschult Do you have a working snippet?

[loadingalias]

I'm looking for a similar solution. Has anyone else figured out out a working structure? Is the relative path to requests.ts the best option?

[fernandojbf]

Hi everyone, I came across this discussion and wanted to better understand how next-intl could work in a multi-app monorepo setup where shared packages are used across different apps.

In my case, I have multiple websites within the same monorepo, each with different routing configurations, but all aiming to reuse shareable parts.

However, the current approach using import { createNavigation } from "next-intl/navigation" requires us to export utilities based on a specific routing integration. In my opinion, it would be more flexible if these utilities could somehow inherit the routing configuration from the application in which they’re being used, rather than requiring a fixed export per route structure.

This would allow us to create reusable modules containing navigation, making composition much easier — since routing is ultimately a responsibility of the application itself, not the shared component or package.

That said, I’ve created a shared package that includes routing, request handling, navigation, and messages. I’m integrating it using:

createNextIntlPlugin("../../packages/i18n/src/request.ts")

But I'm getting an error during integration:

Error: Couldn't find next-intl config file. Please follow the instructions at https://next-intl.dev/docs/getting-started/app-router.

I’m still digging to see if this is a mistake on my side, but I believe it would be awesome if the navigation could dynamically inherit routing from the consuming app. That would make multi-app setups much more ergonomic.

Would love to hear if anyone has experience with this or ideas on how to improve this kind of integration.

[amannn]

Hmm, I see your point. However, inheriting routing config would unfortunately not work with some features like autocomplete for routes, in case you use pathnames. I guess if your architecture really requires to dynamically retrieve a Link, you could also pass one around with React Context.

Error: Couldn't find next-intl config file.

Hmm, with the available information it's unfortunately hard for me to tell what the issue is.

Here's how the check is implemented:

next-intl/packages/next-intl/src/plugin/getNextConfig.tsx

Line 31 in 3192ca1

`Could not find i18n config at ${providedPath}, please provide a valid path.`

[fernandojbf]

Hey,

I just did a bit more debugging on the application, and it turns out the missing next-intl config file issue was actually caused by the Sentry plugin in next.config.js, not by next-intl itself. The order of the compose was preventing the next-intl plugin from being added.

I'll implement a workaround to get the composition working for now, but for larger projects, it would definitely be worth considering a better composition strategy.

[loadingalias]

Working on a solution now.

[johnschult]

Sorry but I've been away. I have this working in a project for work. Let me try to unpack a demo from it.

[RicardoAvans]

Any updates on this? I'm having the same problems when using next-intl as a package inside a monorepo (using it from that package inside an app).

[sakib412]

I am doing this way.
packages/i18n/src/request.ts :

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

import {routing} from './routing';

export default getRequestConfig(async function createRequestConfig({
  requestLocale,
}) {
  // This typically corresponds to the `[locale]` segment
  const requested = await requestLocale;
  const locale = hasLocale(routing.locales, requested)
    ? requested
    : routing.defaultLocale;

  let messages;
  try {
    messages = (
      await (locale === routing.defaultLocale
        ? import(`../messages/en.json`)
        : import(`../messages/${locale}.json`))
    ).default;
  } catch (error) {
    console.error(`Failed to load messages for locale: ${locale}`, error);
    messages = (await import(`../messages/en.json`)).default;
  }

  return {
    locale,
    messages,
  };
});

in packages/i18n/package.json :

...
"exports": {
    ".": "./src/index.ts",
    "./i18n.d.ts": "./src/i18n.d.ts",
    "./plugin": "./src/plugin.ts",
    "./middleware": "./src/middleware.ts",
    "./request": "./src/request.ts",
    "./routing": "./src/routing.ts",
    "./navigation": "./src/navigation.ts",
    "./server": "./src/server.ts",
    "./messages/*": "./messages/*.json"
  },
...

then in my apps/web/src/i18n/request.ts file

export {default} from '@ezy/i18n/request';

I am also able to share my messages type across package or app.

Here how I share types
in my packages/i18n/src/i18n.d.ts file :

import defaultLang from '../messages/en.json';

import type {Locale} from './available-languages';

type Messages = typeof defaultLang;

declare module 'next-intl' {
  interface AppConfig {
    Messages: Messages;
    Locale: Locale;
  }
}

then in other package or app (in my case I used i18n type builder package and in web app)
in packages/builder/i18n-env.d.ts:

/// <reference types="@ezy/i18n" />

// NOTE: This file should not be edited otherwise translation related types may not work

in packages/builder/tsconfig.json:

{
  ...
  "compilerOptions": {
    "types": ["@ezy/i18n/i18n.d.ts"],
    ....
  },
  "include": ["src", "types.d.ts", "i18n-env.d.ts"],
}

Now I am getting full typed next-intl from my local i18n package.

[sakib412]

yes, see my packages/i18n/package.json exports part

[RicardoAvans]

Would you be able to share your middleware.ts from the i18n package? I can't seem to fix my error upon starting the dev server. It's related to the middleware and next.config.ts usage of the package/i18n when the next-intl package isn't installed in my app. So I'm trying to figure out how to solve this :)

[sakib412]

export {default} from 'next-intl/middleware';

[RicardoAvans]

Thanks for sharing! You've helped me solving the error.

[madikmaycryeyewa]

can you share with git repo