Rewrite in Typescript

[axic]

No description provided.

[axic]

@s1na would you be interested in this?

[s1na]

Yeah I would. How do you want the transition to happen? If the whole source (+ tests) are rewritten in TS, I imagine it'll be a somewhat big PR.

[axic]

Not sure yet, perhaps we could start with changing the tests first, then some of the helper libs and finally the rest?

[stephen-slm]

ping 🏓 #442

[sam-goodwin]

Would love to see this implemented. Was it de-prioritized?

[cameel]

See #442 (comment). No one from the team is currently working on this and almost all the work is going on in the main C++ repo.

We have a few open PRs from the community (#205, #298, #442) but they are all pretty old and probably already out of date. The ones from @MicahZoltu look like a good first step so if someone is willing to take over, finish remaining loose ends and bring them up to date, I can help by reviewing them. Probably a lot could also be salvaged from #298 as long as it would be a series of smaller PRs and not one huge PR changing everything.

Given how old these are, I think it would also be fine for someone to just ignore them and start a fresh PR. That might be more motivating than trying to revive code written by someone else. Just please try to do it in smaller steps and not as a complete rewrite of the whole library and all tests in a single PR. That makes it really hard to review properly and have any confidence that it still works as intended.

[MicahZoltu]

The first step is to not rewrite anything but to simply add the build infrastructure and rename the files from .js to .ts. The TypeScript compiler can be instructed to infer any as the type for things that are untyped and to emit even on error.

As a follow-up PR, someone can add type definitions everywhere possible without changing any code.

After that someone can create a PR that changes the minimum amount of code required to disallow any, enable strict type checking, and disable emit on error.

From there PRs can be added to improve the quality of the code now that there is a type checker to help facilitate that.

[stephen-slm]

I'm happy to be the person who starts actioning on this. Including what @MicahZoltu has just mentioned above.

[cameel]

Sounds good to me. @MAMBADEV, if you want to try that, feel free to take over the PRs already submitted by @MicahZoltu.

BTW, if you do any mass renaming, please make sure the renames are in a separate commit without any other changes. This makes it much easier to see in the review what was just moved around and what was actually changed. It also generally helps with conflicts since git can properly see whole files as moved even if you then change them significantly.

[stephen-slm]

That is all fine @cameel, no worries.

I will start staging it, e.g setup the infrastructure (building), renaming etc in one pull request and then allow building on that.

[stephen-slm]

I have gone and started up the first pull request to start the base work for moving into the Typescript space, its #566 and its all open to conversation.

[stephen-slm]

#567 Pull request has just been open to start the process of moving to Eslint.

[cameel]

Just a general update: #566 by @stephensli has been merged recently so we're finally on TS! It introduced some backwards-incompatibility but this is fixed in #595 and #596 so it will not actually show up in a release.

The next step is adding types for development and then types for the exported functions.

[GrandSchtroumpf]

Hello, maybe it can help. Back in the days, I created the types for the input/output compilation for remix-plugin.
You can find the types here : https://github.com/ethereum/remix-plugin/tree/master/packages/api/src/lib/compiler/type
It might not be up-to-date though (version 0.6.x), but it's a good base I think.

[stephen-slm]

HI @GrandSchtroumpf,

exposed types have been added here: https://github.com/ethereum/solc-js/blob/540a9643cd7974e329287ebf8d4c2c70d744c11d/common/types.ts pending a existing PR has to go in first. These are currently in review.

[GrandSchtroumpf]

Hi @stephensli my link above describe the types for the input (language, source, settings) and output (abi, ...) of the compile method based on the solidity input/output documentation.
I can create a separated PR for that if it's fine for you

[roninjin10]

I put up a pr to release types on npm here #693

[stephen-slm]

@roninjin10 it is not that simple, #615 this is the current implementation pending merging, if you want to address the final comments, it will be able to be merged. this types file being the major part of the work.

[EdouardBougon]

Any update on types release ?