Is this singleton insecure in production?

[UROjQ6r80p]

I've read that singleton in i18next might lead to problems in production, not sure if I understood it well.
I have this code:

import i18next from 'i18next';
import Backend from 'i18next-fs-backend';
import { join } from 'path';
import { readdirSync, lstatSync } from 'fs';
import appRootPath from "app-root-path";
import { match } from "@formatjs/intl-localematcher";
import Negotiator from "negotiator";

const localesFolder = join(appRootPath.toString(), './locales');

const languages = readdirSync(localesFolder).filter((fileName) => {
    const joinedPath = join(localesFolder, fileName);

    return lstatSync(joinedPath).isDirectory();
})

const matchLocale = (userLanguages) => {
    try {
        return match(userLanguages, languages, 'en');
    } catch(_) {
        return null;
    }
}

i18next
    .use(Backend)
    .init({
        initImmediate: false, // setting initImediate to false, will load the resources synchronously
        fallbackLng: 'en',
        preload: languages,
        backend: {
            loadPath: join(localesFolder, '{{lng}}/{{ns}}.json5')
        }
    });

function i18nMiddleware() {
    return (req, res, next) => {
        const acceptLanguages = new Negotiator(req).languages();
        const langCookie = req.cookies.lang?.toLowerCase();

        const lng = matchLocale([languages.includes(langCookie) && langCookie, ...acceptLanguages]) || matchLocale(acceptLanguages) || 'en';

       // should i18n instance be created via createInstace() on every request?

        req.t = i18next.getFixedT(lng);
        // use like req.t('hello')

        next();
    }
}

export default i18nMiddleware

Is this code insecure in production? I've read "singleton" might cause troubles with concurrency, and overriding languages.
should i18n instance be created via createInstace() on every request?
I thought in server side (classic old template rendering, not react etc) it's good to preload all languages + all namespaces once, and then the t(...) is just filtering languages and returning the one we want, but it seems the underlying mechanism is different?

[jamuhl]

As long you only use thereq.t that you set - you should be fine. The problem only arises when you directly use i18next.t -> which could be set to any language the last incoming request set - while your pending requests still rely on other languages.

There is also https://github.com/i18next/i18next-http-middleware so there is no need to create this stuff yourself

[UROjQ6r80p]

Thanks, I'll use 18next-http-middleware
I just have one last question cuz I'm confused about part req.i18n.changeLanguage('en') // will not load that!!! assert it was preloaded

I can just use req.t provided by 18next-http-middleware, and don't need to call req.i18n.changeLanguage(...) at all, cuz language is already set by language detector, right?

[jamuhl]

yes, right. you do not need to changeLanguage it will be handled correctly by the language detector (it's there for cases you need to display something in different lng - or other strange use cases).

[UROjQ6r80p]

alright, thank you :)