Hashing doesn't match output of `@lingui/cli`

[maisano-patreon]

I have a rather large application that uses Lingui. We've recently paved the way the be able to adopt swc (including the use of this plugin), and in the process learned that the hashing of strings is not identical across the JS extraction (and babel macro) and this plugin. For one reason or another we have a handful of strings defined with defineMessage that have trailing whitespace. It seems the normalization of whitespace is part of this plugin, but not similarly handled via the babel-based tooling.

There are a few escape hatches on our end that we can rely on to unblock the adoption of swc:

• Providing explicit ids to match our existing strings
• Updating said strings to remove leading/trailing whitespace characters

However, I wanted to flag this as an issue as it's a divergence between the JS and Rust based tooling for Lingui and feels like an oversight. Arguably no string for translation needs to contain leading or trailing whitespace, but I would expect the babel and swc plugins to behave deterministically.

[timofei-iatsenko]

Hello, thanks for your feedback. What versions of swc plugin & @lingui/cli do you use?

I recently changed whitespace handling in both babel and swc version, this change is planned for v5. You can start using it now, via next tag.

However, even for the v4 implementation it is a bug, and it shouldn't normally happened. Would be interested in the STR case, to prove that this not happened in the v5.

[maisano-patreon]

I'm currently using version 4.0.9 of the swc plugin (we're on Next.js 14) and version 4.7.1 of the CLI.

[timofei-iatsenko]

Do you have an example which produces different hashes?

[maisano-patreon]

Yea, here's one of the instances from our app:

defineMessage({
  message: 'Poster fill with full bleed ',
}),

The CLI extracts this with the id of W7FeOI. The swc plugin compiles this away and provides the id of ngM89i.

If I remove the trailing whitespace and re-extract, the CLI will emit this id in the same form as the swc plugin.

[maisano-patreon]

After testing this a bit more, it appears this only happens when the message property has additional whitespace. When a context property has unnecessary whitespace it does not impact the hashing.

[maisano-patreon]

Another instance of a string hashing differently is:

defineMessage({
  message: 'Hi\n\nhello',
});

Again, these newlines don't belong in this message, but this does not behave the same w/ the swc plugin.