next-i18next: [8.0.0-beta.4] Error when using postProcessors

Fixed via a serializeConfig option in #972.

Unfortunately, publicRuntimeConfig has performance implications and cannot be considered. Please check the docs:

A page that relies on publicRuntimeConfig must use getInitialProps to opt-out of Automatic Static Optimization. Runtime configuration won’t be available to any page (or component in a page) without getInitialProps.

Your proposed solution is:

1. Maintain a convention of next-i18next.config.js file
2. Continue to import next-i18next.config.js file inside serverSideTranslations to save users some trouble
3. Require users to import their next-i18next.config.js file in _app and pass as an argument.

Correct? I think we have indeed talked in circles a little bit here, but @LeonardDrs’s point about closures and imported dependencies is pretty conclusive. I don’t think we’re going to find a way around that.

@LeonardDrs I don’t understand this:

It bothers me a bit that every pages are going to require the configuration solely for the purpose of server/build-side. The client-side page.js file will have a “useless” import of a configuration object. Unless we specify that the config import/require needs to be located in the getStaticProps/getServerSideProps functions?

I agree with you @isaachinman and I’m curious as to what will happen with Next plugins. To be honest I think the dream is that a framework API is so simple and nice that Plugins don’t need a “plugin API”. We’ve kinda seen this with Next, but I guess people are finding more and more complex use cases that it’s needed now.

Well unless somehow the module could import ../../next-i18next.config.js in appWithTranslations and serverSideTranslations, I feel like your pr https://github.com/isaachinman/next-i18next/pull/930 is the way to go.

Edit: Actually, unless I’m missing something @filipesmedeiros, your PR only require the consumer to pass the config (if any) once, in _app.tsx like so:

import type { AppProps } from "next/app";

import i18nextConfig from "next-i18next.config";
import { appWithTranslation } from "next-i18next";

const App: React.FC<AppProps> = ({ Component, pageProps }) => {
    ....
};

export default appWithTranslation(i18nextConfig)(App);

since the serverSideTranslations already requires the userConfig:

const DEFAULT_CONFIG_PATH = './next-i18next.config.js';
...
if (fs.existsSync(path.resolve(DEFAULT_CONFIG_PATH))) {
    userConfig = await import(path.resolve(DEFAULT_CONFIG_PATH));
}

so… all good?

Yeah I agree

but now I’m feeling that this could be a Next responsibility since they are the ones serializing props, but I don’t know if they would be keen on implementing it. Especialy since it may be wrong to share instances/functions this way?

I think maybe we should focus on creating a nice/easy way to make config shareable on the app side, and not on ours

Somewhat related to #930. I wonder if @filipesmedeiros has an opinion on how we might best avoid all these serialisation errors?