[5.0.0-next.1] useLingui() macro doesn't work if you don't use t

[AndrewIngram]

I've been trying out the latest version of the macro, the macro form of the useLingui hook works great if you include t in the destructuring, but breaks if you don't.

eg these work:

const { t, i18n } = useLingui();
const { t } = useLingui();

but this doesn't

const { i18n } = useLingui();

We want to consistently use the macro form, so this is a bit of an issue.

However, we primarily want the i18n object so we can access i18n._ for handling message descriptors constructed elsewhere, but it seems like we can just pass these objects to t without issue?

[timofei-iatsenko]

this is a bug, i will take a look.

However, we primarily want the i18n object so we can access i18n._ for handling message descriptors constructed elsewhere, but it seems like we can just pass these objects to t without issue?

It might work, but it is not how I supposed to use it, so it's better to avoid passing objects to t destructured from useLingui macro

[AndrewIngram]

speedy, thanks!

Is there a way to cut another release that doesn't include the swc version bump? As incorporating that would require us to upgrade to Next 15 canary, which we're not really in a position to do yet

[AndrewIngram]

@thekip @andrii-bodnar looks like the babel version of the macro explicitly doesn't support this case, is that now an oversight?

See https://github.com/lingui/js-lingui/blob/next/packages/babel-plugin-lingui-macro/src/macroJs.ts#L223-L232

[timofei-iatsenko]

The idea of those errors was that useLingui should be explicitly used with object destructuring, a not in a any other forms, such as

const lingui = useLingui()
lingui.t`Ola!`

But you are right, that might throw an error in your usecase as well. i'll create a tests case and fix in js repo as well.