react-i18next:: i18n.languages were undefined or empty undefined

Describe the bug

I get the the following error:

[ wait ]  compiling ...
react-i18next:: i18n.languages were undefined or empty undefined

which appears only on the server (I mean in the output of the terminal, it doesn’t appear on the browser console).

Occurs in next-i18next version

“next”: “^8.1.0”, “i18next”: “^17.0.6”, “next-i18next”: “^0.44.0”,

Steps to reproduce

I followed every step described in the readme except keySeparator (because I have keys like Status.ONGOING)

Below is my configuration:

import NextI18Next from 'next-i18next'

const instance = new NextI18Next({
  defaultLanguage: 'en',
  otherLanguages: ['ru'],
  keySeparator: false
})

export default instance

Expected behaviour

This doesn’t look like a critical error, though I’m wondering the cause.

Screenshots

OS (please complete the following information)

• Device: MacBook Pro (Retina, 13-inch, Late 2013)
• Browser: Chrome Canary Version 77.0.3838.0 (Official Build) canary (64-bit)

Additional context

• I’m working on a monorepo (yarn workspaces)
• I use TypeScript

[isaachinman]

Finally took some time to dig into this. The issue of awaiting the initialisation of the i18next instance is a very trivial one, and I can provide an easy, non-breaking way for users to do that if they want to. However, I think that that race condition is causing a very low percentage of the error reports we are seeing here.

The main problem is indeed with 404s, primarily in development. This is because a browser makes a request for a dev resource which used to exist, but now has been cleared by HMR. Eg:

http://localhost:3000/_next/static/webpack/f15dd305991bb90f87e1.hot-update.json

This request goes through the next-i18next middleware first, and as far as we are concerned, this is a request for a static resource and has a statusCode of 200 (has not been modified yet). The default behaviour here is to exclude static resources from i18next-express-middleware, thus req.i18n shouldn’t exist on this request.

The request then gets passed to NextJs:

const handle = app.getRequestHandler()
server.get('*', (req, res) => handle(req, res))

At this point the request is determined to be a 404, and the status code is changed. At that point in time, NextJs wants to render an error page, but does so without a redirect (naturally), so the next-i18next middleware never gets called again, and we do not have a chance to populate the i18n instance.

That NextJs logic can be found here.

(It’s noteworthy that this code path is different than “normal”, non-resource, 404s which next-i18next handles just fine.)

The curious part is how react-i18next ever gets to the point of calling hasLoadedNamespace, as i18n.isInitialized is a precondition of that call, and i18n shouldn’t exist on that req at all. Still not sure about this, but it’s relatively unimportant.

In general this is a bit of a chicken-and-egg problem to solve. The easy thing to do is to remove the passing of ignoreRoutes to i18next-express-middleware, seen here.

The actual redirect logic is protected by isI18nRoute which uses the exact same ignoreRoutes array, so we actually don’t have to worry about static resources being redirected when users have enabled localeSubpaths.

However, this solution would mean that we are processing all our static resource requests through the i18next middleware, just on the off chance that one of them results in a 404. Perhaps this is actually the right thing to do? No idea if this has perf implications, but it probably does.

On a side note, I have no idea why the NextJs team have decided to return an HTML doc for a 404 on a JSON resource - that doesn’t seem right to me. Not sure if that’s configurable.

Apologies for a long post, but that’s the entire story. We have all the information necessary to work on this, it’s just a matter of discussing amongst ourselves what makes the most sense.

Open for discussion.

[murat-mehmet]

I had the same issue on first page load efter every npm start. Added the following in i18n.ts:

NextI18NextInstance.i18n.languages = ['en', 'tr', 'fr'];

Seems like it suppressed the warning.