Typescript rewrite

[GrandSchtroumpf]

Add :

• tsconfig.json.
• package.json : @types/node + @types/bn.js.
• test/index.js : change RLP directory to dist/index.js.
• src : typescript files.

TODO:

• tests in TS
• linting
• prettier
• make sure that it works with: Recursive Typings #35
• remove original JS sources
• Remove dependency on yarn
• Update README
• Make sure that package importing works (entrypoint etc)
• Extract common config
• figure out BigNumber imports SKIPPED (note by @krzkaczor) so current typings are pretty shitty and they forces us to use it in this way. We could fork/create our package. I already done so in evm-ts. This allows to use normal syntax for import. I would say it's low priority for now 🤷‍♂️ )

[coveralls]

Coverage decreased (-2.0%) to 89.286% when pulling a3c8ded on typescript into 5849c7b on master.

[holgerd77]

Hi @GrandSchtroumpf, great initial work, thanks so much, also cool to see the tests already passing! 👍 We can leave this open for some time for some further tooling discussion and for improvements from other PRs integrated here, seen that @krzkaczor has already started with #38.

[holgerd77]

Probably a linting update PR (we had a strong tendency for Prettier for this) can also be done by @krzkaczor, so that tests are passing?

[holgerd77]

Some addition to using TypeScript strict: I also had some discussion with Matthew @mattdean-digicatapult (who is currently doing great StateManager refactoring work on the VM) on this: Matthew was also very supportive of making type checking as strict as possible, but he also pointed out that this could make initial transition effort significantly larger since there can be the need of a lot more changes to the original JS code compared to a non-strict approach (depending very much on the structure of the initial code base). So it might make sense here to loosen this go-for-strict approach on a first round, just for the sake of not overloading on changes, and target this on a second update round.

But we can very much see how this is turning out on practical experiences and then decide how to proceed library-by-library.

[krzkaczor]

@holgerd77 yeah i think thats a valid point but this is very small lib so i guess it wasn't difficult to do it at one go.

[holgerd77]

@krzkaczor Whew, that was a quick merge! 😄 We can do this for non-master branch related merges. Just want to make sure and for others to note: this is not setting things in stone, just providing a more unified ground for further discussion (if needed).

[holgerd77]

@GrandSchtroumpf Do you think you'll find some time today or tomorrow to answer the comments here from @krzkaczor? Then we maybe can have this adopted or finalized.

[GrandSchtroumpf]

Tomorrow yes.

[holgerd77]

@GrandSchtroumpf I think you should generally remove (by rebase) your last commit, otherwise it will get super-messy for @krzkaczor to rebase on top of this (@krzkaczor: please correct me if I am wrong).

Can you just copy-paste your #35 issue fixing changes to somewhere, delete the last commit and then resubmit (without the semicolon changes, this is already introduced in the PR form Chris) as a separate PR?

[holgerd77]

Once you are ready please also push-force (push --force) the branch here with the last commit removed, than @krzkaczor can do the last changes, rebase on top of this and we can get this merged. Probably better to do this sooner than later since changes introduced there are pretty broad in scope.

[holgerd77]

Since we are slowly getting to some common ground on configuration and setting? Do you guys think it is viable to have some of this configuration extracted to an external dependency - ethereumjs-config or something, I think one of you once mentioned that?

How would this work regarding the integration and what config parts would be applicable to that? Do you have any example where this is done in practice and/or some article link on this?

[holgerd77]

@krzkaczor Very cool, have set up the following repo:
https://github.com/ethereumjs/ethereumjs-config

If you are doing a PR on this that would be great, then we could further discuss along the design choices made within the PR!

[GrandSchtroumpf]

@holgerd77 yeaah... I know, I think I'm a bit obsessed too ^^.

[holgerd77]

For now added some coverage thresholds for failure (85% absolute, -2.5% relative), so that CI should pass on next trigger.

[holgerd77]

I would give this a go. Before we merge I think @GrandSchtroumpf and/or @whymarrh should also have a final look and we should wait for at least one more approval.

[holgerd77]

Update review after latest documentation merge, looks good.

@GrandSchtroumpf @whymarrh Can you also have a final look so that we can get this over the finish line? 😄

[whymarrh]

There are a few deprecated utils used here but we can remove those separately.

@GrandSchtroumpf @krzkaczor @holgerd77 this is great work! 👏🏽👏🏽👏🏽

[holgerd77]

Merged. 😄