Js-lingui: @lingui/loader inside GatsbyJS project throws an error

[sedubois]

Describe the bug
I have a project where I can successfully use <Trans id="hello" />, but i18n.t`hello` doesn't work in development (just prints the key), and when building the static site it gives the error WebpackError: i18n.t is not a function.

To Reproduce

import { I18n, Trans } from "@lingui/react"

export default function App() {
  return (
    <I18n>
      {({ i18n }) => (
        <React.Fragment>
          <div>
            {i18n.t`hello`} // --> doesn't work, renders hello
          </div>
          <div>
            <Trans id="hello" /> // --> works, renders bonjour
          </div>
        </React.Fragment>
      )}
    </I18n>
  )
}

Expected behavior
Should render bonjour, bonjour instead of hello, bonjour in dev, and should not raise build errors.

Additional context
Add any other context about the problem here.

• jsLingui version 2.6.1
• Babel version [email protected]
• Using Gatsby v1 and with this (partial) package.json config:

{
  "dependencies": {
    "@lingui/react": "2.6.1",
    "babel-plugin-transform-class-properties": "6.24.1",
    "babel-plugin-transform-object-rest-spread": "6.26.0",
  },
  "devDependencies": {
    "@lingui/babel-preset-react": "2.6.1",
    "@lingui/cli": "2.6.1",
    "babel-plugin-dynamic-import-webpack": "1.0.2",
    "babel-plugin-import": "1.8.0",
    "babel-plugin-syntax-dynamic-import": "6.18.0",
    "babel-webpack-plugin": "0.1.1",
  },
  "scripts": {
    "lingui:extract": "BABEL_ENV=lingui-extract lingui extract",
  },
  "babel": {
    "presets": [
      "env",
      "react",
      "@lingui/babel-preset-react"
    ],
    "env": {
      "lingui-extract": {
        "plugins": [
          "transform-class-properties",
          "transform-object-rest-spread",
          "syntax-dynamic-import",
          "dynamic-import-webpack"
        ]
      }
    }
  },
  "lingui": {
    "fallbackLocale": "en",
    "sourceLocale": "en",
    "localeDir": "src/locale",
    "srcPathDirs": [
      "src/components",
      "src/layouts",
      "src/pages"
    ],
    "format": "minimal"
  }
}

[FredyC]

Apparently, the Babel plugin failed to transform i18n.t to i18n._, but I am not sure why. Would be really helpful if you could setup reproduction repo, it's hard to investigate issues like this without full context.

[tricoder42]

i18n.t is available only in development. Babel converts it into i18n._ which is the only i18n method used in production.

Try to run lingui extract with different BABEL_ENV, rather than overriding NODE_ENV:

BABEL_ENV=lingui-extract lingui extract

[sedubois]

OK OK, I'm trying to isolate the problem, but now even Trans won't work for some reason (maybe I removed too many things from my project).

Here is what I got so far, if you have an idea:
https://github.com/sedubois/lingui-i18n-debug

I also changed to use BABEL_ENV as suggested, which doesn't change the problem. (Updated OP.)

[sedubois]

I've updated the repo to properly reproduce the issue I face:
https://github.com/sedubois/lingui-and-styledjsx-debug

(it still contains styled-jsx config as I'm also trying to fix logging issues related to that)

[tricoder42]

It seems that gatsby ignores .babelrc and you need to modify it through Node API. I've added a PR to your repo https://github.com/sedubois/lingui-and-styledjsx-debug/pull/1

Related docs: https://www.gatsbyjs.org/docs/node-apis/#modifyBabelrc

[sedubois]

Thanks @tricoder42. To be clear, the babelrc isn’t needed at all for Gatsby but I started to add it so that Lingui would work. Is there a way to avoid all this redundant Babel config?

[tricoder42]

If you need just the lingui-extract section, they you could use the extractBabelOptions in configuration: https://lingui.js.org/ref/conf.html#extractbabeloptions

[sedubois]

OK thanks, at least now it all works! 🙂 At some point we should probably simplify this with a plugin or something.

Also I'm still confused by the fact that this starter seems to work without tweaking the Gatsby node API as you suggested:
https://github.com/dcroitoru/gatsby-starter-i18n-lingui

[tricoder42]

Me as well 🤔

Soon or later we should create an official starter or plugin, or at least document it with Gatsby v1 and v2. There's lot of info hanging in GitHub issues...

[sedubois]

Actually it still doesn't work in production with a more complicated translation key, I've pushed the new example here:
https://github.com/sedubois/lingui-and-styledjsx-debug/commit/41caac9d1ac00bfee76c525e8e8011780b17290d

To reproduce:

git clone https://github.com/sedubois/lingui-and-styledjsx-debug
cd lingui-and-styledjsx-debug
yarn
gatsby build
gatsby serve

[tricoder42]

Ah, I see, because plural actually performs formatting and you need a compiled catalog for this.

Alright, here's the plan: I'll review the workflow over the weekend. In some cases compiled message catalogs aren't required and it might be enough to compile them at runtime. I'll create a documentation for GatsbyJS, example in Gatsby repo and review few starters I saw around.

I'll get back to you on Monday.

In the meantime, I added PR to your repo.

[sedubois]

Thanks @tricoder42, as explained in PR https://github.com/sedubois/lingui-and-styledjsx-debug/pull/2, lingui compile is needed for more complicated translations. However this prevents translations to be reloaded on the fly during development, i.e. HMR doesn't work when changing a messages.json file (because messages.js needs to be rebuilt manually). Is there a way to fix that?

[tricoder42]

Hmm, since GatsbyJS uses webpack, you might want to use @lingui/loader and change the imports:

- en: require("./locale/en/messages.js"),
+ en: require("@lingui/loader!./locale/en/messages.json"),

[sedubois]

Thanks, that syntax does not seem to work just like that with Gatsby, throws Cannot find module '@lingui/loader!./locales/en/messages.json' (I used yarn add -D @lingui/loader).

Should some kind of custom Gatsby configuration be added? I don't really know what to do of the documentation.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[FredyC]

@tricoder42 Do you consider issues marked with "bug" as obsolete too? I want to remind you that a lot of issues here are "stale" because of the delay with V3 release. It doesn't necessarily make them invalid even though they are older.

[tricoder42]

All developers get an email notification that the issue they opened is marked as stale. If they're still interested, they can come in and contribute.

Nobody says these issues are invalid. They're just marked as stale because, probably, there's no longer anyone who would like to work on them.

If this bug affects you, feel free to fix it and send a PR 👍

[FredyC]

This specific issue doesn't affect me, I just find it "weird" to ditch even confirmed bugs. Doesn't matter if the original author is still bothered by it, but if the bug is not solved, then it's still valid no matter what. That's my opinion.

And email notification? Since when? It must be an insane person to enable something like that 😆

[tricoder42]

The bug was confirmed two years ago. Is it still relevant now? Does it affect latest version? If so, fix it, send a PR. Otherwise there's no point keeping it open. It's not a security issue (in fact, security issues are never marked as stale)

And email notification? Since when? It must be an insane person to enable something like that 😆

I believe that's the default GitHub behavior — when you create an issue, you automatically get notifications from it. You can always opt-out.