-
Notifications
You must be signed in to change notification settings - Fork 237
TypeScript Migration #142
Comments
@chikeichan I believe it has been concluded that this is desired. See some discussion here: ethereumjs/organization#28 and the plan on the organizational roadmap: https://github.com/ethereumjs/organization/blob/78199a9ab5462274cf645813549dad0278b12e01/docs/roadmap.rst For ethereumjs-tx, there may be some bigger redesign needed anyway. We may want to do this prior too, or at the same time as, the typescript rewrite. I will write some notes on broader needed changes and link here, and we can consider best approach before a typescript rewrite states. Also note that there is an open PR that does some work on typescript in this repo: #88 It will likely be closed once we commit to a clear migration plan for the whole repo. |
Hi @danjm, thanks for pointing to those links. My original plan was to just add types to the library. I wasn't aware of a plan to redesign it, but I'm open to it. After working a little more with the library I see your point. I also noticed that it's based on ethereumjs-util's defineProperties, which has been deprecated in this commit. Is there a plan to move away from it? Is there a new pattern for ethereumjs libraries? |
@alcuadrado you can read up on this PR ethereumjs/ethereumjs-account#27 for the account library on the state of the defineProperties discussion, the method-removing code didn't make it in the final version though, mainly for temporary compatibility considerations. This is also some good TypeScript transition reference PR one can go along, since we also updated lots of tooling along with this change. |
One alternative to One possible addition: define a In the end it comes down to how much boilerplate is too much. The current approach in An ideal solution would maximize benefiting from typescript types, is readable and doesn't introduce too much boilerplate in each of the types. But if there's no solution we could also continue using |
Oh, and since re-structuring is being discussed, I'd like to ask for comments on something else I've been thinking about (from ethereumjs/ethereumjs-monorepo#494):
|
I branched off #144 and started migrating this library. I'll submit a PR in draft mode, as there are multiple things that I'd like to get feedback about. I went with Chris' approach, as I don't want to introduce breaking changes. Once typed, refactoring should be easier. @s1na's ideas are rinteresting, should we keep that discussion here, or create a more general issue somewhere else?
Do you mean explicitly adding them? If not, the situation would be similar to add the types and use
This type sounds like it would be really handy.
Personally, I'm ok with some boilerplate in exchange for easier to understand code, and getting more static guarantees.
This sounds good. I once worked on a bitcoin library designed in this way. The base layer was immutable, and mapped to the protocol level representation's of things (that'd be RPL in ethereum). It was a nice design, but the project was abandonned so I can't tell how ergonomic it felt to work with it as a consumer.
How would this work from an user of the library's perspective? Would they have to be aware of the different classes? |
I'm closing this issue now that #145 is merged. |
From Pato (Nomic)
We are really interested in the migration to TypeScript, as we use TS for everything in Buidler. Some of the few places where we have untyped code is due to ethereumjs-tx, so we'd love it to be typed. All of its dependencies are already in TS, so migrating it should be straightforward.
Would love to kick off a discussion on whether this is needed/desired. Specifically trying to see if this is an issue that can begin now.
cc-ing recent contributors for discussion: @holgerd77 @danjm @youfoundron
The text was updated successfully, but these errors were encountered: