Js translation files cannot obtain TS type support

[SAKURA-CAT]

Hi, thank you very much for developing this project, which has solved our team's text internationalization issues! Now we are encountering a problem: in version 3.0 of next-intl (e.g., 3.26.5), we could easily replace JSON files with JS files.
Doing so has the advantage of distributing translation files across various components, reducing the mental burden during our development process. For example:

import { en as componentsEn } from '@/components/messages'
import { en as appEn } from '@/app/messages'
import { en as hooksEn } from '@/hooks/messages'

const en = {
  components: componentsEn,
  hooks: hooksEn,
  ...appEn
}

export default en

In global.d.ts:

import en from './messages/en'
import React from 'react'
import { Metadata } from 'next'

export type Messages = typeof en

declare global {
  // 使用 `next-intl` 的类型检查
  type IntlMessages = Messages
  // React 组件的 props 类型
  type LayoutProps<T = NonNullable<unknown>> = Readonly<T> & Readonly<{ children?: React.ReactNode }>
  // metadata 返回值
  type PageMetadata = Promise<Metadata>
}

However, in version 4.0, while the original translation feature remains functional, the TypeScript type support feature has ceased to work:

import en from './messages/en'
import React from 'react'
import { Metadata } from 'next'

declare global {
  // React 组件的 props 类型
  type LayoutProps<T = NonNullable<unknown>> = Readonly<T> & Readonly<{ children?: React.ReactNode }>
  // metadata 返回值
  type PageMetadata = Promise<Metadata>
}

declare module 'next-intl' {
  interface AppConfig {
    Messages: typeof en
  }
}

Is there a way for me to use a JS file as a translation file in 4.0 with TS type support?

BTW, I reviewed the issues, and this situation is similar to #1894, but we are not overly concerned about the impact of translation files on the response speed of the compiled pages.

[amannn]

Hmm, I don't see an obvious problem with that code snippet.

Can you share a repro based on next-intl-bug-repro-app-router? Happy to take a look!

[SAKURA-CAT]

I found that this was caused by the TS call stack exceeding the limit after I wrote a recursive type calculation—not entirely sure why this issue wasn't detected in version 3.0.

I'll close this discussion. Thank you for your reply!