Support createMessagesDeclaration for pages router

[alexjamesmacpherson]

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

With the v4 release of next-intl, type-safe message arguments is now possible, which is a very exciting prospect for closing one of the last loosely-typed gaps in our application!

However, the existing documentation around the feature suggests it is an experimental behaviour exposed only to the app router implementation, as it needs to be set in the createNextIntlPlugin config blob, which is not utilised by the pages router, and which throws if called by a page-routed app.

I appreciate that this behaviour is currently only experimental, but it would be awesome if it could be exposed for those of us using the pages router too - especially given Vercel plans to continue support for the pages router in Next.js "for many years in the future"!

Describe the solution you'd like

Exposing the createMessagesDeclaration utility such that it can be called in the Next.js config file to generate the declaration file would be great - or really any other way of exposing this functionality to page router implementers.

Describe alternatives you've considered

1. Migrate our application to the app router (infeasible)
2. Accept no support for type-safe message arguments 🙁

PS. Loving next-intl - thanks for all the work you've put in to make it as awesome as it is! 🙂

[amannn]

Hmm, that's a fair point. To add to this, also apps that use the core library use-intl will have the same issue.

In an ideal world, the TypeScript team would address microsoft/TypeScript#32063, which would make the need for this entirely obsolete. But despite the popularity of the request, it doesn't look like anything is moving in that issue currently.

The createMessagesDeclaration option really doesn't do much: It simply takes your messages file and wraps it into a declaration file:

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

Lines 65 to 71 in 3192ca1

	function createDeclaration(content: string) {
	return `// This file is auto-generated by next-intl, do not edit directly.
	// See: https://next-intl.dev/docs/workflows/typescript#messages-arguments
	declare const messages: ${content.trim()};
	export default messages;`;
	}

Additionally, in development a watcher is started:

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

Lines 38 to 42 in 3192ca1

	compileDeclaration(messagesPath);
	if (env === 'development') {
	startWatching(messagesPath);
	}

We could of course offer a standalone CLI, but it would increase the API surface for something I'd like to get rid of at some point anyway.

Another option that would come to my mind for your particular case is that we could allow to set requestConfig to e.g. null, in order to indicate that you want to use the plugin, but don't link to a file like i18n/request.ts which would be required for App Router usage. This would be a pragmatic solution that would be possible with a smaller amount of changes, but it doesn't address all cases.

Might need to think a bit more about this—I wonder if there's another solution.

/cc @stefanprobst I think you asked for something similar.

PS. Loving next-intl - thanks for all the work you've put in to make it as awesome as it is! 🙂

Thank you so much! ❤

[stefanprobst]

i am currently just calling createI18nPlugin in a separate script, which gets called in the npm prepare lifecycle. this is totally good enough for my usecase.

// scripts/generate-i18n-message-types.ts
import createI18nPlugin from "next-intl/plugin";

createI18nPlugin({
  experimental: {
    createMessagesDeclaration: ["./messages/en.json"],
  },
})();

console.log("Successfully generated i18n message types.");

and package.json:

{
  "scripts": {
    "prepare": "tsx ./scripts/generate-i18n-message-types.ts"
  }
}

[alexjamesmacpherson]

i am currently just calling createI18nPlugin in a separate script, which gets called in the npm prepare lifecycle. this is totally good enough for my usecase.

Sweet, this workaround suits me also - thanks @stefanprobst!

[github-actions]

This issue has been automatically closed because there was no recent activity and it was marked as unconfirmed. Note that issues are regularly checked and if they remain in unconfirmed state, they might miss information required to be actionable or are potentially out-of-scope. If you'd like to discuss this topic further, feel free to open a discussion instead.