Message extraction fails when using both Globalize.formatMessage and <FormatMessage>

[alunny]

PR is just a failing test case - I can try to fix if you don't have time to have a look.

[alunny]

I think I've found what's up, should have a real patch shortly.

[rxaviers]

👏 👍

[alunny]

So part of the problem (at least in a test case) is that react-globalize-compiler doesn't transform _globalize2['default'] into Globalize, as globalize-compiler does.

Should react-globalize-compiler depend on globalize-compiler? I don't really want to just copy that transform into here, although that would be the quickest fix.

[rxaviers]

Using the transform in here as well sounds good to me. Ideally, Globalize should adopts the same strategy for default messages that react-globalize has. Then, we'll be able to move all this stuff into globalize-compiler (where it should live).

PS: About variable names, the ideal solution should keep a table of variables (per scope) dynamically generated from require("globalize"), or define(["globalize"...) calls, orimport` declaration. But, that is much more complex.

[alunny]

I found this useful during debugging - not strictly necessary.

[rxaviers]

Interesting 👍

[alunny]

I think we'll want to do the same for messageFormatter calls as well as formatMessage btw.

[rxaviers]

Sounds good to me, thanks.

[alunny]

this is a duplicate file now (this was already in extract-default-message-transforms but not exported)

[alunny]

Should be ready to merge now.

[rxaviers]

For consistency, let's move lib/extract-default-messages-transforms/babel-globalize2-default-into-globalize.js to lib/extract-transforms/ given it's used by both default-messages and normal compiler?

[rxaviers]

Other than one comment above, it looks good to me.

[alunny]

updated now :)

[rxaviers]

Thank you @alunny, landed and published by 0.0.6.