-
Notifications
You must be signed in to change notification settings - Fork 122
Add support for processing intl.formatMessage
when injection is used.
#165
Conversation
I'd love to see this merged 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also need this!
Thanks @swernerx! This works a treat! To the maintainers, our app had something like 1,500 formatMessages, the prospect of converting them to use defineMessage was not appealing. As this person pointed out in 2016 this should be really obvious in the docs. Although preferably this pull request would be merged! |
Ack. will review asap |
I see this was committed in formatjs/formatjs@b57953e by @longlho Unfortunately with it being enabled by default it is causing extraction failures in my usage of
and used as follows: Without the suggested option to make this change opt in and no obvious way to opt out of this functionality I needed for now to downgrade |
@macca16 can u create an issue in formatjs/formatjs? THanks! |
3.0.2 is broken for us because of formatjs/babel-plugin-react-intl#165 `formatMessafe()` calls are not recognized as coming from injectIntl().
3.0.2 is broken for us because of formatjs/babel-plugin-react-intl#165 `formatMessage()` calls are not recognized as coming from injectIntl().
3.0.2 is broken for us because of formatjs/babel-plugin-react-intl#165 `formatMessage()` calls are not recognized as coming from injectIntl().
In our project we had the need to extract from
intl.formatMessage
as well. According to your documentation this is a feature you do not want to include by default. I perfectly understand the reasoning that it is hard, by any system, to automatically check whether it's theformatMessage
injected byreact-intl
.In our case we would prefer using
formatMessage
and life with the risk that some calls might be wrongly analyzed. We just follow the convention that to make it parsable theformatMessage()
call has to be called in theintl
object. In our application we feel this limitation is pretty safe - and might be for a lot of other uses.I opened this PR for our team to use and for a general discussion on the topic. Probably we can add a parameter to the plugin to enable this non-safe extraction as well.
What do you think?