Upgrade to React 18

[HelNershingThapa]

This PR upgrades the front end to the latest React 18 with other changes supporting the same.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[HelNershingThapa]

The build appears to fail because the new bundle size exceeds the the'maximumFileSizeToCacheInBytes' value of 2MB.

The overall bundle size has been reduced from 14.26MB to 14.01MB with React 18, but the size of the main file has nearly doubled from 3.11MB to 6.02 MB. Previous builds passed because the the'maximumFileSizeToCacheInBytes' in the previous webpack version v4 was 5 MB, and the main file used to be only 3.11 MB. But the limit is only 2MB with the new webpack v5—I checked the value from the webpack.config.js file inside the react-scripts package inside node_modules.

Treemap for older bundle:

The inclusion of the node modules portion in the new build is what I expect to cause this increase in the size of the main file. In the treemap visualization below, the node modules contribute 2.96MB, nearly half the size of the main bundle, but this is not the case in the older treemap--the node_modules portion is excluded. To generate the treemap with your build, run 'yarn analyze'.

Treemap in this PR:

Even if we exclude the node_modules portion from the bundle, it will still exceed the maximum file size limit(2MB); the generated bundle is 3.13 MB(refer to the treemap viz below). I used a third-party library, react-app-rewired to generate a bundle excluding the node_modules chunk, and the treemap viz looks as follows:

I'm hesitant to eject because, in addition to contaminating the project with numerous files, it would undermine the abstraction provided by create-react-app, our current boilerplate. @ramyaragupathy I'd appreciate it if someone could take a look and have any suggestions for a workaround or fix—these webpack configs always go above my head :/

[ramyaragupathy]

@emi420 - is this something you can help with?

[emi420]

Hey @HelNershingThapa yes, a 2mb bundle is big, but 6mb is way too much.

There are a couple of things you can do:

• Install UglifyJS
• Be sure that the NODE_ENV=production environment variable is configured in the server
• Serve the front end gzipped
• Take a look to the Code-Splitting guide

[HelNershingThapa]

Hi @emi420, Thank you for your suggestions; UglifyJS and gzip are already used in our development process. I'm also confident that the production environment variable is set when the build is generated. I've also tried route-based code-splitting for some components, but it didn't add much to the overall build—just a few KBs in size reduction; perhaps there's more to it. Code splitting is complex because it disrupts user experience in some ways due to dynamic imports and lazy loading, and we'd also have to deal with fallbacks when the import is loaded. I'm lenient for a configuration that excludes node_modules from the build and then code split if necessary. Thanks.

[tsmock]

Looking at the two images, it looks like polyfill.js is the problem.

I did some investigation when I was looking at updating all frontend dependencies.

• Current browserslist is ">0.2%", "not dead", and "not op_mini all". This would be Chrome 103+, Edge 107+, Firefox 107+, Opera 92+, and Safari 14.1+.
• We can drop @formatjs/intl-relativetimeformat (4.2M raw, see Intl.RelativeTimeFormat for the browser-supported version). 93% of global users should not be affected, and those that are should update their browser. For that matter, all of our "supported" browsers support it.
• We can drop @formatjs/intl-pluralrules (117K raw, see Intl.PluralRules for the browser-supported version). 93% of global users should not be affected. All of our "supported" browsers support what we use.
  • Firefox does not support Intl.PluralRules.selectRange. We don't use it.
• We can drop @formatjs/intl-locale (92K raw, see Intl.Locale for the browser-supported version). 93% of global users should not be affected. All of our "supported" browsers support the full API.

Dropping the polyfills reduces the number of chunks from 1603 to 27 and the total size from 15.06MB to 11.25 MB (this was with fully updated dependencies).

EDIT: As an addendum, most of the rest of the 3 MB of main.<hash>.chunk.js for me was the locales (en.json, es.json, etc.)

[ramyaragupathy]

@varun2948 @tsmock - do you see this following up after,
Update react scripts
Update query string

[tsmock]

Both of those PRs were copied from #5721 in an effort to try and do some upgrades in steps. I've closed both PRs since they are no longer necessary.

[varun2948]

I think this is now irrelevant too as all this changes have been merged with the #5721 PR . Its good to close right ? @tsmock

[tsmock]

I believe that this draft PR can be closed as well, yes.