[SIMPLE PATCH READY] Simple hack for compatibility with Turbopack (NextJS)

[Palid]

Hi! 👋

Firstly, thanks for your work on this project! 🙂

Today I used patch-package to patch @lingui/[email protected] for the project I'm working on.

I've been trying to setup turbopack with my project due to enormous compilation times, and figured out why things do not work as expected - it's the loader expecting webpack environment, even though it's not really doing anything with the module definitions.
With a simple change, the loader is now turbopack-swc-compliant.
Maybe there's a better way to figure out

Just for documentation reason, I'm additionally including my next.config.js, so that documentation for NextJS+SWC loader+Turbopack can be improved in the future. :)

/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
  experimental:
  {
    swcPlugins: [["@lingui/swc-plugin", {}]],
    turbo: {
      resolveExtensions: [
        ".mdx",
        ".tsx",
        ".ts",
        ".jsx",
        ".js",
        ".mjs",
        ".json",
        ".po",
      ],
      rules: {
        "*.po": ["@lingui/loader"],
      },
    },
  }
};

module.exports = nextConfig;

The usage differs a little bit after using Turbopack, as it's going to be just direct imports like shown below.
You no longer need the prefix of @lingui/loader! before your imported .po files!

async function loadLinguiMessages(lang: Lang) {
  if (process.env.NODE_ENV === "development") {
    return (
      (await import(
        `src/locales/${lang}/messages.po`
      )) as MessagesFile
    ).messages;
  } else {
    return translations[lang].messages;
  }
}

Package versions, but most likely any nextjs version with turbopack will have the same problem:
"next": "^14.1.0",
"@lingui/loader": "^4.6.0",

I might try to solve this with a proper PR, but adding a simple patch like this is definitely better than just leaving it be!

Here is the diff that solved my problem:

diff --git a/node_modules/@lingui/loader/dist/index.cjs b/node_modules/@lingui/loader/dist/index.cjs
index e478911..75c8e0a 100644
--- a/node_modules/@lingui/loader/dist/index.cjs
+++ b/node_modules/@lingui/loader/dist/index.cjs
@@ -45,7 +45,7 @@ Please check that \`catalogs.path\` is filled properly.
   const strict = process.env.NODE_ENV !== "production";
   return api.createCompiledCatalog(locale, messages, {
     strict,
-    namespace: this._module.type === "json" ? "json" : "es",
+    namespace: '_module' in this ? this._module.type === "json" ? "json" : "es" : 'es',
     pseudoLocale: config.pseudoLocale
   });
 };

This issue body was partially generated by patch-package.

(I have decided to leave this template, as it's pretty slick and I think more people could use it. 😄 )

[thekip]

Thanks for the patch. Do they have documentation about compatibility of turborepo with webpack loaders?

As far as I understand from your patch when loader is executed by turborepo, there is no this._module variable, and it probably crashes when it accesses this._module.type. Am I right?

Just for context:

condition:

namespace: this._module.type === "json" ? "json" : "es",

Made to overcome the issue with webpack. Webpack doesn't allow (at least with public methods) switching type of the module in the loader. It means if you're loading "*.json" module through loader webpack expects json output from this loader. When you load any unknown to webpack module such as *.po or *.png file, webpack expects a valid ES module as output.

So this poses a problem, lingui user may load and compile catalog using *.json extension (lingui or minimal catalog formats) and using *.po format. Loader should work for both of the cases. That's the purpose of this condition.

[Palid]

@thekip It does not break compat with webpack by chacking if we have this._module though. If we do - just go through with webpack part, if we don't we're probably in different bundler (e.g. turbopack).

It's just a quick&dirty hack to make sure this works, as turbopack makes compilation so much quicker.