Any support for passing an actual config object instead of withNextIntl(/* path for i18n/request.ts */) plugin?

[paulsohn]

So I'm working on my next project with your next-intl app, and struggling to get a grip for how everything is configured correctly.
Using webpack aliasing plugin for i18n/request.ts or other file path works but hacky, and it doesn't even work well with file reference tracker (e.g. in many IDEs like vscode moving a file triggers update import prompt, but i18n/request.ts does not.)

---

I have no test yet, but I would expect the usage flow might be like:

// i18n/request.ts
import { getRequestConfig } from "next-intl/server";

const request = getRequestConfig(async () => { /*...*/ });
export default request;

as before, and then somewhere in the setup you can import this request as an object and call setGetRequestConfig(request) to actually apply the intl config, without specifying by the path name i18n/request.ts.
The new function setGetRuntimeConfig will be like

// in next-intl/src/server/react-server/createRequestConfig
import getRuntimeConfig from 'next-intl/config'; // error throwing fn
import type {GetRequestConfigParams, RequestConfig} from './getRequestConfig';

export function setGetRequestConfig(cfg){ // the function we've just called
  getRequestConfigRef.value = cfg;
}

export default const getRequsetConfigRef = {
  value: getRuntimeConfig as unknown as (
    params: GetRequestConfigParams
  ) => RequestConfig | Promise<RequestConfig>
};

// and modify every getRequestConfig usage to getRequestConfigRef.value

Basically it will give more freedom and clearer interface. It is just so pointless to be confused by 'the latest docs says to make i18n/request.ts but I have older version that only supports i18n.ts' or vice versa like #1309 .

[amannn]

I see your point, I'd prefer i18n/request.ts be registered as a JS module too instead of via an alias. The constraints with Server Components however asked for a design like this—e.g. @next/mdx follows a similar approach.