Drop deprecated formatter libraries

[Chevindu]

Description

This change updates intl-messageformat dependency version so that it fixes following npm deprecation warnings logged when installing react-intl-universal in a project.

npm WARN deprecated intl-messageformat-parser@3.6.4: We've written a new parser that's 6x faster and is backwards compatible. Please use @formatjs/icu-messageformat-parser
npm WARN deprecated @formatjs/intl-utils@2.3.0: the package is rather renamed to @formatjs/ecma-abstract with some changes in functionality (primarily selectUnit is removed and we don't plan to make any further changes to this package
npm WARN deprecated @formatjs/intl-unified-numberformat@3.3.7: We have renamed the package to @formatjs/intl-numberformat

Type of change

• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes.

• Edited Test Case: HTML Message with XSS attack
• Added Test Case: HTML Message with variables and custom XML parser

[SamuelLeclerc33]

Is this going to get merged ? @cwtuan

[cwtuan]

Is it possible to avoid making a breaking change?

[Chevindu]

I noticed the upstream library (formatjs) does not support the full HTML spec as rich text according to this part in their docs.

We could add support for a limited set of HTML/XML tags in react-intl-universal and allow users to override it during init(). But I did not do it due to following reasons:

• I could not think of a sensible default that would fit all use-cases of the library.
• Maintainers of the package may have to keep up with the future requests to add inbuilt support for specific XML tags.

Thus I added the option of xmlParser to allow users to define the parsing they want to use in their messages. This part would need a documentation update, which should probably also point to the limitations mentioned in the upstream documentation.

[cwtuan]

Thank you for your reply. As you mentioned, this change will require an update to the documentation. Could you please update the README?

[Chevindu]

I'm sorry about the delay. I just updated the docs. Feel free to adjust/correct my wording.

[SamuelLeclerc33]

Bump @cwtuan

[cwtuan]

Thank you for your contribution to this upgrade. The new version of intl-messageformat shows promise in handling rich text messages effectively. However, the potential for breaking changes could lead to disruptions in existing applications.

Internally, we're actively discussing strategies to mitigate these concerns and provide developers with the necessary tools to transition smoothly. Our suggestion is developing a tool to scan application source code and assist developers in writing correct messages. We believe such a tool could be immensely valuable in helping developers identify and address any potential issues introduced by the update.

We'd love to hear more about your thoughts on this idea and any insights you might have on how we can best implement it.

[cwtuan]

Another approach is to implement a new function such as intl.getComponent that supports rich text, while ensuring that the intl.getHTML function remains compatible with its previous behavior.