Implement strict type system

[toschdev]

Typechecking will make the implementation more secure.
e.g. https://flow.org

Aimed for Lisk-JS 1.1

---

Updates:
A decision has finally been made for TypeScript.
Aimed for Lisk-Elements 2.0

Child Issues

• Set up TypeScript for lisk-elements Set up TypeScript for lisk-elements #781
• Migrate @liskhq/lisk-cryptography package to TypeScript Migrate @liskhq/lisk-cryptography package to TypeScript #797
• Migrate @liskhq/lisk-passphrase package to TypeScript Migrate @liskhq/lisk-passphrase package to Typescript #798
• Migrate @liskhq/lisk-api-client package to TypeScript Migrate @liskhq/lisk-api-client package to TypeScript #799
• Migrate @liskhq/lisk-transactions package to TypeScript Migrate @liskhq/lisk-transactions package to TypeScript #800
• Migrate @liskhq/lisk-client package to TypeScript Migrate @liskhq/lisk-client package to TypeScript #801
• Migrate lisk-elements package to TypeScript Migrate lisk-elements package to TypeScript #802

[alepop]

I propose to consider Typescript instead of Flow

[alepop]

My points to use Typescript:

• Typescript is a compiler with support for new Javascript features (es6/7/8, async/await, decorators)
• React support out of the box (relevant to lisk-nano project)
• This allows you get rid of babel
• Easy setup (webpack + ts-loader + tsconfig.json file)
• You can move your project to Typescript incrementally with one field in config file

[kazzkiq]

In addition to @alepop, I would like to take some points where TypeScript shines over Flow:

• Typescript is a superset of JavaScript, which means it not only provides type-checking, but it actually adds other features on top of it, without losing compatibility with JavaScript code. This means that features not seen in JavaScript such as Interfaces, Enums, Classes (out of the box), Decorators and others are all supported by default, but you only use them if you want to. It also have ES6/7 support out of the box, compiling to ES6 (and bellow) if needed.

• Flow is a great tool in what is was made for, that being the possibility of adding a tiny "typecheck" layer on top of your JavaScript code while leaving everything else up to you (afaik).

TypeScript on the other hand is at another level, it managed to build a terse language set around JavaScript itself, and extend JavaScript to the point it can compete with mature languages, while maintaining the dynamic features of the JS ecossystem.

The work Microsoft made in TypeScript was surprisingly good (not usual if you take into account their historical open-souce decisions), and by assigning personalities like Anders Hejlsberg to work on it only shows its commitment to the language.

So, back to Lisk. Since we're talking about an (awesomely) huge project, aimed to handle serious money and serious code in form of dApps I cannot think of a better option for the job than TypeScript.

[Bit-Shifts]

The argument of Typescript vs flows totally depends on what you are trying to accomplish. If you are just looking for a strict type system I would suggest flow as this is just a think layer on top of your JavaScript code, where Typescript is a fundamental shift away from pure ES and is becoming its own language. Also Typescript is not out of the box ready for React. Yes Typescript does have added functionality but is also not ecmascript compliant in many cases. Typescript was originally designed so C# developer could wrap their head around JavaScript where Flow was created to help JavaScript developers.

This all depends on what you are aiming for with future development.

Flow: If you are just looking for strict types
Typescript: If you want to take advantage of some of the added features typescript has

[vitaly-t]

B.t.w., pg-promise comes with comprehensive TypeScript support out of the box: https://github.com/vitaly-t/pg-promise/tree/master/typescript

[jondubois]

I'm not a huge fan of compile-to-js languages for large/complex projects because:

• They add additional complexity/brittleness to the build step.
• It means that you have to wait a bit longer for builds each time you want to test your code. In spite of all the marketing, I am yet to see actual 'fast' builds on any real large TypeScript project that I've worked on.
• Sometimes Node.js modules don't have type definitions available on definitelytyped (or they're out of date) and that's annoying - Developers sometimes end up mixing statically typed and dynamically typed syntax to accommodate dynamically typed modules into the code base (or worse; you write the type definitions yourself).

Also source mapping isn't always smooth sailing when it comes to debugging; especially in more complex environments like Node.js.

I would vote against (for Lisk core) but if everyone else wants this then I can cope :p TypeScript code completion is nice if your IDE supports it.

If I have to pick one, I would choose TypeScript over Flow because of maturity/stability.

[vitaly-t]

TypeScript also compensates for the lack of tests a lot.

For example, you make a change a repository method, and forget to update the code somewhere where it is used, and that's not yet test-covered. TypeScript will stop you right there, if there is any parameter or return type mismatch. So it adds to a much more robust code. Type checking is a powerful thing 😉

[jondubois]

@vitaly-t Good point. For me this almost makes it worth the pain points I mentioned above. Almost ;p

I find that if method names are meaningful then it's not usually difficult to find all references in the source using text search commands/IDE shortcuts. I guess it depends on personal taste and tooling of choice.

[shuse2]

Additonal to what @JakeSimmons89 said,
I think it's like relationship between JAVA(Typescript) and Scala(plane javascript).
If we refactor it to Typescript, there will be architectural differences.
Of course we can organize it in the same way, but I think TypeScript has it's own way of coding.

I think what @jondubois and @vitaly-t said applies to both TypeScript and Flow,
both needs build step: flow needs to remove typedef, and typescript needs to compile to JS (although flow is bit faster imo)
for type definition: flow also doesn't have defined type, so might need to add, or you leave it as dynamic. (which is similar to TypeScript)
using strict flow, does compensate for some testing.

Partial refactoring using TypeScript is harder than using flow.
Additionally, to completely replace it, it takes time and it might introduce new bugs.

On the other hand, flow does work on top of the current project. Therefore, it has immediate effect.
Unless we want to make significant architectural difference, I would vote for full ES6 feature with babel and flow, which will have immediate effect than TypeScript with less effort.

[webmaster128]

+1 for Typescript because of it's popularity. Every Angular developer is familiar with it and on StackOverflow it is 50k vs. 1.3k.

[tobiaslins]

@webmaster128 Popularity should not be the reason why we or someone should use a specific technology. Neither Stackoverflow questions (could also mean that TS is more complicated for example)

Even tho there are more Pure JS devs then TS devs I guess.

I would not force people to use Typescript. For example, I would not contribute anymore if it would be changed.

Flow is just an extra layer that will not change the way everything is coded.

[GarrettS]

No, typechecking will not make anything more secure.

But you’ve gone on for so long talking about your favorite JavaScript libraries while providing no example of why not type checking makes your JavaScript less secure indicates that you really don’t know what the flip you’re doing.

It might appease the insecurities of developers who don’t know JavaScript.

[webmaster128]

Type checking usually does not make code more secure, but it makes it safer. It is way easier to spot bugs or inconsistencies when the compiler or even your IDE tells you that you put in a variable of one type where another type is expected. And it is very easy to do this kind of bugs. For example: what type is a hash? Sometimes it is a hex string, sometimes it is a Buffer. There are many methods that work on both types, so even when running the code it is not guaranteed you spot a bug.

For everyone who criticizes type checking and never worked with it: give it a try. Start a simple Angular project (or whatever framework you like), use TypeScript and use Visual Studio Code as an editor. Don't stop using it after a day. Do it for 1 month and let your project grow. Do refactoring with the support of a type system. Productivity goes up quickly because you don't need to run tests very often. You avoid a lot of bugs. Your code becomes easier to read for the future you. You'll love it.

[willclarktech]

A decision has finally been made for TypeScript. We will aim to include it in v2.0.0 of Lisk Elements. To everyone involved in this conversation, thank you very much for contributing to the discussion. The decision in the end rested on two main points: (1) the increasing dominance of TypeScript vs Flow as a typing solution for JavaScript, and (2) the compatibility with other libraries in the Lisk ecosystem (in particular pg-promise and oclif). To everyone who was arguing in favour of Flow, sorry to disappoint you. We hope you can respect our decision.