Celo SDKS (ContractKit) compile target

[aaronmgdr]

Currently CeloMonorepo TSconfig is set to target "es5"

This means old browsers can run the code but also results in a larger bundle size as new ECMAscript features are implemented inline.

[mcortesi]

Without extra information, i'd say es6. What do we gain by using es2017?

[aaronmgdr]

biggest specific difference is es2017 assumes async await is supported.

generally newer mean smaller package sizes but more risk of not being supported in some environments. (Although I think 5 years is a decent enough time personally)

[fbaud]

Voted for es5.

While I understand the argument of smaller bundle size and the drawback of carrying legacy code, more too often we are safer using older code versions than newer ones for compatibility with multiple libraries and tools.
At some point, this argument is reversed because most tools no longer support older versions, but it's always tricky to anticipate when this happens.

[aaronmgdr]

i think about now is the time when most tools no longer support es5.

[fbaud]

What tools are you primarily thinking of?

I suppose babel would qualify as an important tool to consider as well. I've lately spent a couple of days on issues with the "Support for the experimental syntax 'jsx' isn't currently enabled" issue and it must be considered that several tool chains are still using older version of the different tools (my case).

[aaronmgdr]

my understand is that there have been several years where both all released browsers and node versions support es6/es2015 features. so unless someone is building celo dapps that run on versions older than those released about 2017ish then they have no need for transpilation to the older es5 from 2009

[fbaud]

My point was that browsers are only part of the equation. When you have a tool chain based on somewhat older versions of react, react-scripts, babel, webpack,... any change in one of the libraries could potentially disrupt the building process and would prevent upgrading to newer versions of the library. From my particular point of view, it's always safer to keep things as they are than change them while there is no urgency to do it (if it is not broken, don't fix it). That explains why I voted for es5. But that's my specific situation.

[fbaud]

Hi Aaron,

I tried to find some statistics on the javascript versions of the packages published on https://www.npmjs.com/ but did not find much.

Maybe a way to objectify the upgrade of the compile target version would be to set a minimal version of create-react-app and create-react-native-app that should be able to run without problems coming from eslint, babel, webpack,... with the standard built-in configs.

As an example, I still have repos built with create-react-app v3.4.3 and create-react-native-app v3.5.1.

Once you have set minimal versions, it could help validating if any change of compile target is having potential or minimal impacts.