i18next-express-middleware should not be included to the client bundle

I noticed that the size of my app’s client bundle soared after switching to next-i18next from a custom react-i18next integration. As it turned out, the reason was that i18next-express-middleware ended up included into the bundle, which pulled quite a few other modules and made _app.js grow from 5KB gz to 123KB gz.

I tried wrapping require() in create-i18next-client and next-i18next-middleware into eval locally, but that did not help.

It feels a bit strange that the export of i18n.js contains both a hoc and a middleware – that is hard to three-shake. Can the middleware thing be moved to another file and used in server.js only? I mean somehow like this:

// server.js
const i18n = require("./i18n");
const nextI18NextMiddleware = require("next-i18next/express-middleware");
// ...

(async () => {
  await app.prepare();
  const server = express();
  nextI18NextMiddleware(i18n, app, server);

  // ...
})();

To achieve that, i18n can be an uninitialized instance of the original i18n, which gets initialized when it’s used as an argument. Same for hoc?

import i18nHoc from "next-i18next/app-hoc";
import i18n from "../i18n";

const MyApp = ...;

export default i18nHoc(i18n)(MyApp);

Overall, the idea of exporting a single default object in i18n.js and then importing its fields in server.js and _app.js has compatibility issues with TypeScript (see example app, where server.ts uses import instead of require).

UPD: Wrapping i18next-express-middleware into eval actually helped. Bundle size was not decreasing in my first experiment because there was one more require in my custom middleware that I forgot to eval too.

[isaachinman]

Update: it looks like adding next-i18next to a project will increase your commons chunk by just over 400kb (no gzip). That’s not great, and as I said it’s my top priority now.

[isaachinman]

Would really appreciate a second opinion so that we can (relatively) safely release v0.9.0.