You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The macro itself is something that not exists in runtime. It's precompiled during build step. There some limitations what could be done with the macro and how it can be used. Some valid ecmascript constructions might not work with a macro.
I'm thinking of creating a rule which will check for unsupported syntax and give faster feedback to developer.
Calls on a member expression (macro.t`Ola!` vs t`Ola` ) has a completely different AST representation and each case should be handled by the code manually. It's easier to just disallow this usage at all.
All eslint rules in this plugin match lingui symbol just by name. Despite the fact macro itself is able to handle renamed imports, this will literally turn off all eslint checks for lingui. So it's better to disallow this.
Passing macro as value
The example is using a new useLingui hook from lingui v5 for demonstration purpose, but this issue could be reproduced with a plain t macro as well.
export{useLingui}from'@lingui/react/macro';functionbuildFormValidation(t){constmyErroMsg=t`Field is Required`}functionMyComponent(props){const{ t }=useLingui();// disallowbuildFormValidation(t);}
The developer may want to pass t macro as a value to the other functions, but because t doesn't exists in the runtime that will lead to error. These usages should be disallowed.
Note: there is only one valid case for such usage, t from useLingui could be used in a deps array of react hooks.
For the same reason as for with imports, macro exported from useLingui should be used only with object destructuring.
Renaming should also be blocked because it will disable eslint checks on these calls.
The text was updated successfully, but these errors were encountered:
The macro itself is something that not exists in runtime. It's precompiled during build step. There some limitations what could be done with the macro and how it can be used. Some valid ecmascript constructions might not work with a macro.
I'm thinking of creating a rule which will check for unsupported syntax and give faster feedback to developer.
Namespace import from macro
Calls on a member expression (
macro.t`Ola!`
vst`Ola`
) has a completely different AST representation and each case should be handled by the code manually. It's easier to just disallow this usage at all.Renaming macro symbols
All eslint rules in this plugin match lingui symbol just by name. Despite the fact macro itself is able to handle renamed imports, this will literally turn off all eslint checks for lingui. So it's better to disallow this.
Passing macro as value
The example is using a new
useLingui
hook from lingui v5 for demonstration purpose, but this issue could be reproduced with a plaint
macro as well.The developer may want to pass
t
macro as a value to the other functions, but becauset
doesn't exists in the runtime that will lead to error. These usages should be disallowed.Note: there is only one valid case for such usage,
t
fromuseLingui
could be used in a deps array of react hooks.useLingui
macro usage correctnessFor the same reason as for with imports, macro exported from
useLingui
should be used only with object destructuring.Renaming should also be blocked because it will disable eslint checks on these calls.
The text was updated successfully, but these errors were encountered: