TypeScript Transition

[holgerd77]

This issue should help to work out a TypeScript transition strategy for the different EthereumJS libraries and discuss strategies, collect best practices and inform about caveats.

[whymarrh]

A lot (all?) of the projects currently adhere to the "standard" JS code style. Is there a desire to keep that (i.e. tslint-config-standard) or are we open to reconsidering the rules in the context of TypeScript?

[holgerd77]

I would in most cases in such situations be a fan of keeping standard rules / best practices, to avoid new maintenance work, since in most cases I have the impression that this is mostly a question of taste. What would be your main motivation(s) to change/adopt rules here?

[vpulim]

Have we considered using Flow instead of TypeScript? In the context of EthereumJS, Flow has a few advantages:

• Flow integrates seamlessly with existing transpilers like Babel (which libraries like ethereumjs-vm already use). It is possible to use TypeScript with Babel, but its pretty hacky (the Babel transpiler strips out all TS annotations before compiling so you must separately use TS tools to do error checking before running Babel)
• Flow annotations can be added using comments so it doesn't break existing code when not using a transpiler. This is not the preferred way to annotate types, but it can be useful when incrementally transitioning EthereumJS modules to Flow without breaking existing dependencies.
• Flow has much better deep type inferencing, which lets you do a lot more error checking out-of-the-box without adding any type annotations at all.
• Flow annotations are simple additions to any existing JS code, whereas TypeScript is a superset of ES6 so once you start using TypeScript language features, you are basically locked in to using TypeScript going forward.

I'm not trying to start a Flow vs TypeScript war (in fact, I would probably use TypeScript myself when starting a new project from scratch). But, in this particular instance where we have a lot of existing JS code spread across lots of modules, all using different build processes, Flow makes more sense to me in terms of incrementally getting the benefits of type checking without breaking a ton of things in the process or having to spend a lot of time re-writing code and build configurations.

I'm not pushing hard on this, but I just wanted to make sure we've considered all options before getting locked in to TypeScript since it will be hard to switch later. I'll be happy either way since adding static type checking to EthereumJS libraries will be a huge win no matter which approach we take.

[axic]

@vpulim my goal when I've first pitched the idea (https://github.com/etherts/pm) was to rewrite the base (ethereumjs-util) library as well as those which are in need of a redesign anyway.

In that case there's no problem of keeping both JS and TS code at the same time.

[vpulim]

@axic I see. If libraries are being re-written anyway, then starting with a new TS-based implementation makes sense. 👍

[holgerd77]

There is currently a relatively strong momentum within EthereumJS towards TypeScript.

One major thing is that this brings us closer to a code base compatible with WebAssembly through projects like AssemblyScript and there is the hope that there will be major cross-benefits once eWASM is getting ready for production.

And this momentum also comes strongly from the community, there have been various requests on TypeScript from different sides lately, also have the impression that TypeScript is strongly gaining momentum lately in the JavaScript community as a whole.

I am nevertheless an expert in neither the one or the other and we might want to have some discussion around this, the points you mention are definitely also valid. Actually babel integration into the libraries is not as deep as one might think on first sight, this is often just integrated by somewhat pretty simple configurations.

Maybe @whymarrh also wants to join the discussion here, since he just volunteered to do a TypeScript rewrite for the RLP library.

[axic]

More links.

Consider reaching out to @krzkaczor (met him at Web3 Summit) for joining efforts with https://github.com/ethereum-ts and https://github.com/ethereum-ts/evm-ts.

Consider reaching out to @ricmoo for joining efforts. See more at etherts/pm#1

Also not sure what https://github.com/ethereumts is 😕

[krzkaczor]

@axic i managed to get a devcon ticket 👌 I am happy to meet all of you here and discuss 😉

[ricmoo]

Awesome! I’m heading to the venue right now! Should be there by 10. Once I’m checked in, I will be hanging out at the Grant Showcase and at 3 I’ll be presenting ethers.js on the Rhapsody stage, come bug me anytime, and if anyone can’t find me and wants to chat anytime throughout DevCon4, email me@ricmoo.com and I’ll come find you. :)

[holgerd77]

Cool, looking forward to an exchange! 😄

[krzkaczor]

I want to leave here a bunch of tips for TS development as we talked about it with @holgerd77 IRL:

• use --strict mode - this is the single most important thing. I am talking about strict type checker mode, not use strict from JS. This enables a bunch of other flags like --strictNullChecks, --noImplicitAny etc. improving enormously type safety of TS.
• use tslint with good ruleset. Consider TypeStrict (by me ;) )
• consider using prettier for formatting instead of tslint (it reformats your code from AST avoiding a need to manually format your code entirely) (the same would apply to eslint)
• consider ts-essentials to reuse common types

All my projects follow these rules; you can check how it looks like here.

And as we spoke, don't hesitate to add me as a PR reviewer if you're having troubles with TS or just need another pair of eyes 😄

Happy Typescripting! 🎉

[holgerd77]

Hi @ricmoo, I was unsure if we find some common ground (I am still a bit actually), that's why I didn't ask earlier, but if you want you are also very much invited to join, we will exchange on TypeScript in the Tea Room (no idea where this is 😄) at around 10 am today. Maybe we can discover some areas where collaboration is possible between the advanced ethers.js libraries and the basic EthereumJS library suite. We also maybe do some coding and some exemplary TypeScript conversion of one of the simpler EthereumJS libraries.

Best
Holger

[ricmoo]

@holgerd77 Heya! I won’t be there by 10, but would love to chat. I’ll drop by the tea room when I get there, to see if you are still there. Otherwise, I’ll ping you this afternoon too. :)

[holgerd77]

@ricmoo Cool! 😄

[holgerd77]

@krzkaczor Thanks for writing this up, I am very much open for many of the suggestions. Actually I was thinking if would make sense to just let you alone with @whymarrh and others and figure out yourself what best practices you think would make sense to establish, since you guys are actually the experts and know TypeScript way better than me.

[krzkaczor]

@axic @ricmoo its next to xanadu room (2nd floor)

[holgerd77]

This issue was not followed-up, TypeScript transition was mostly organized along the respective repositories and generally close to complete. Will close here.