Upgrade frontend libraries

[kxmbrian]

• Make necessary changes to upgrade for React 15.5 and to prepare for React 16.
• react-summernote has not made the upgrade. Submitted a PR to the repo for that. Right now, it only generates warnings.
• Following up to Standardise frontend date and time formatting #2278, removed timeZone prop is no longer required as a prop to IntlProvider. Switched to using yahoo/react-intl instead of jeremyyap/react-intl.

[allenwq]

👍 @kxmbrian Does the libraries in the webpack config need to be updated ?

[kxmbrian]

Update: react-summernote PR has been merged, but maintainer has not published the latest package.

Latest changes:

• Updated the webpack config from webpack 1 to webpack 2 syntax.
• Use import + webpackChunkName instead of require.ensure.
• Removed some externals from webpack config - even though it is the recommended setup for enzyme, we don't seem to need it for your jest setup, i.e. removing it does not results a Error: Cannot resolve module....
• Upgraded yarn version in package.json.
• css-loader, jest , redux-logger , glob, react-redux , style-loader versions have moved since PR was first made.

Note: you might have to reinstall the node-sass package on your local machine if you get this issue. I did yarn remove and yarn add, but you can try yarn install --force

[allenwq]

@kxmbrian Is the import here async ? If it is then we will need to load_modules after import success.

From their examples it seems that we might need sth like:

Promise.all([import("intl"), import("intl/xxx")]).then(function() {
    load_modules();
});

[kxmbrian]

Updated!

[kxmbrian]

@weiqingtoh Have made another PR to react-summernote to expedite the update, however, even if it were merged, we will still get warnings because the latest build of react-summernote uses Promises but phantomjs does not support Promises natively.

It is possible to polyfill it for the time being, but it might be better to swap out phantomjs instead #2270. Shall we leave it for now and use the production build instead of the test build when testing locally?

Related to #2307 (comment).

[weiqingtoh]

@kxmbrian My main concern is whether or not we are able to catch critical JS errors using the production build - because it does ignore some js errors after all. Would it be possible to study that?

The move to chrome headless might have to wait a little cause it still requires for us to manually build chrome locally, and I'm not too keen to impose that on the development team yet. If the polyfill does not take a significant amount of time, I think it's all right to do that first.

[kxmbrian]

Yup, I agree that we should let all JS warnings come to light and we should wait a while before moving to headless chrome.

Made a PR for the polyfill #2309

[weiqingtoh]

👍 Thanks @kxmbrian !