TS compilation target is quite old

[alcuadrado]

Hi,

First of all, I love this initiative. Having consistency across the TS/JS Ethereum community would add a lot of value.

Reading the different configs, the tsconfig.json's target caught my attention. Is it really necessary to compile to ES5? There aren't many platforms that don't support, at least, ES-2016 natively. The ones that don't are not supported anymore by their authors, and they shouldn't be used for security sensitive stuff (eg: anything we do with Ethereum).

I think that defining a set of supported environments and then deriving a config from there would result in smaller and more comprehensible bundles (sometimes source-maps aren't available). The bad news is that typescript doesn't do that automatically, but it's not a lot of work either.

[holgerd77]

Will answer tomorrow in more detail, did some own research, just dropping the link - also for own - reference: https://medium.freecodecamp.org/you-might-not-need-to-transpile-your-javascript-4d5e0a438ca

[holgerd77]

Hi @alcuadrado, I really love that this sparks discussions like this!

I have to admit that we DO only have some swampy picture for what platforms we actually develop. We have now these new organizational docs and it would be great if out of this discussion comes some list of platforms we actually support and can add in the technical reference section so that we have a write-up of this and some point for updated discussion and changes.

Regarding ES5 we did have some complaints lately form people using some build tools further along the road which only supported ES5 JS, this is an example for that, generally do a ES5 organization-wide search, you will probably find other example issues.

But we shouldn't crystallize around the above too much and just start with an open discussion on what platforms to support first and then have a look at the examples stated above and decide case-by-case if these are a) widely used platforms which justifying support and b) didn't update in the meantime so that support isn't necessary any more.

Cheers
Holger

P.S.: Pretty much busy with Christmas stuff the coming days, this might be some discussion to be continued in January. 😄 🎅 🎄

[alcuadrado]

I have to admit that we DO only have some swampy picture for what platforms we actually develop. We have now these new organizational docs and it would be great if out of this discussion comes some list of platforms we actually support and can add in the technical reference section so that we have a write-up of this and some point for updated discussion and changes.

I think defining such a list would make many decisions easier for ethereum-js devs and the wider around it.

Regarding ES5 we did have some complaints lately form people using some build tools further along the road which only supported ES5 JS, this is an example for that, generally do a ES5 organization-wide search, you will probably find other example issues.

I did that search and all the issues seem to be related to UglifyJS. This is an abandoned project, but until recently there are weren't any serious/winning contender and was still used by default in webpack. Now many projects are moving to Terser, including webpack 5 which will make many more projects (inadvertently) adopt it.

But we shouldn't crystallize around the above too much and just start with an open discussion on what platforms to support first

Completely agree. For instance, I think major bundles (eg: webpack) should be supported platforms, which would shed some light about when the compilation target can be changed.

a) widely used platforms which justifying support and b) didn't update in the meantime so that support isn't necessary any more.

There are many things to define, like which are the supported platforms, and a policy about which of their versions are supported.

My initial suggestion for supported platforms:

1. Major browsers: Chrome, Firefox, Safari, Edge
2. Crypto-friendly browsers: Brave. Opera?
3. Node
4. Major bundlers: Webpack, browserify, rollup
5. React Native

PS: Sorry for the late answer

[holgerd77]

Note: numbered your platform list for easier reference + fixed a typo.

Thanks @alcuadrado for the great write-up 👍, that already gives a lot of additional clarity!

Did the search, uglify-js still has > 8 Mio weekly downloads on npm. Not a total killer argument, but just for stating and further discussion. We can't take care for every single tool in the JavaScript toolchain, but also not sure where to draw the line there.

You supported platform suggestion already makes a lot of sense and - yes - I think I encountered most of it already in the one or the other PR or issue, just didn't make the effort to systematically get them together yet. If we would start with that and systematically/periodically re-check on this list, this would already a lot better compared to where we are now.

Didn't think of 2) yet but definitely makes sense to keep a special eye on that too. Just lately played around with both and crypto support (Opera) respectively the whole project (Brave) is really moving fast and we should recognize and value these efforts.

[alcuadrado]

Did the search, uglify-js still has > 8 Mio weekly downloads on npm.

Sorry, forgot to mention this. Webpack 5 hasn't been released so virtually every webpack user is using uglify. Changing the TS compilation target now will break things for a lot of people. Should we move this discussion to another issue?

Not a total killer argument, but just for stating and further discussion. We can't take care for every single tool in the JavaScript toolchain, but also not sure where to draw the line there.

I'm not sure either. That's why I mentioned bundlers in particular, as they tend to drive the usage of other tools. I'm only experienced with Webpack, and maybe that's not the case for every bundler though.

It may make sense to define some rules around this, like "only this kind of tools and only if they have X marketshare in their category". I wouldn't be surprised if after defining such a rule only webpack passes it, which would make things easier.

If we would start with that and systematically/periodically re-check on this list

Yes, I don't think this should be 100% up-to-date either. Just having a clear list of what's supported and a way to propose changes to it would be great.

Didn't think of 2) yet but definitely makes sense to keep a special eye on that too. Just lately played around with both and crypto support (Opera) respectively the whole project (Brave) is really moving fast and we should recognize and value these efforts.

If this adds too much work maybe these platforms can be aggregated as Chromium. I'm not sure how they manage upstream changes, but I guess they keep in sync with them.

[holgerd77]

Addressed in #28, will close.