Fix: Remove typescript typings

[levino]

Fixes #1658
Also fixes #1659

Happy to discuss.

[levino]

Also check in the issue and here DefinitelyTyped/DefinitelyTyped#26031

[coveralls]

Coverage increased (+0.08%) to 83.921% when pulling 857edf6 on Levino:feature/ISSUE-440-remove-typings into 9bf5803 on ethereum:1.0.

[levino]

My PR over at DT passes now. My local code compiles with it. We should have more tests for the types though. Happy to support any work on this. This PR here can be merged now if the principle approach is appreciated.

[levino]

Good morning, my PR for @types/web3 has been merged. Now it is time to act. Either remove the type definitions from here or make a PR adding a stub at DefinitelyTyped that tells people who try to install @types/web3 that there is no need because type definitions are provided by the package itself.

[frozeman]

Can we have a call, i would like to understand the typescript issues more.

[levino]

Will contact you later or tomorrow.

[levino]

Feedback from in person review:

• Remove all typescript stuff from package.json

• Document typescript usage of web3 in readme or so

[levino]

I did not commit the changes lerna bootstrap made to the package-lock.json do not create a discussion. I will open another PR to commit the changes created by the command.

[levino]

Done. @frozeman let me know if you have a better place for the typescript usage documentation.

[frozeman]

Is there a link to the web 3 typescript repository, you want to include?

[levino]

I did. https://github.com/DefinitelyTyped/DefinitelyTyped It is just one gigantic repo for all type definitions for all npm packages.

[levino]

I do not understand why CI build is not passing. Need help @nivida

[frozeman]

seems like he cant build the script package: scrypt@6.0.3 install: node-gyp rebuild npm ERR! Exit status 1

Your additions shouldnt have changed anything. I will merge and fix locally.

[donamk]

Who maintains type definition now? I do not think it is a good way to get rid of all type definition from the web3.js repo. There is a wrong definition about eth.personal.unlockAccount().
Where are the three parameters?

These awful things happen very easily if the main repo does not include type definitions.

[levino]

The definitions are maintained outside of this repo at DT (Defnitely Typed).

Please read https://github.com/ethereum/web3.js/tree/326e42fe3687d3e34840dbe4797408dfe6364917#usage-with-typescript

Also read this

https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html

If your package is not written in TypeScript then the second is the preferred approach.

If you find a bug, create an issue at DT. Even better: Make a PR for the definitions at DT.

Thank you.

[donamk]

@levino do you think it is a good idea to download whole definitelytyped repo for just a small PR? What I insist is it is good to have a separate type definition repo until web3 has really solid functions.

[donamk]

@levino Here is my PR. DefinitelyTyped/DefinitelyTyped#28753
Seriously, there are so many bad types. I cannot fix it all one day.
I will fix it one by one when I have some free time.

[levino]

Please work on your attitude. We are just following best practices here. Thank you for your contribution, I will review whenI have time. Possibly others will review before the that.

[donamk]

@levino What attitude? Could you tell me the detail which things you don't like?
I just speak out my thoughts. My opinion can be different from yours. I have no idea what is the problem. Anyway, if you speak to me what my attitude you don't like, I will try to fix it.

First of all, I like typescript. I attend many Typescript meet up in many countries. Most of the javascript developers suffer from wrong type definition when they start Typescript. Then they should complain to the library developers but they complain the Typescript. I hate to see that typescript is blamed by just a few wrong type definitions.

Secondly, like as bignmber.js, many libraries decided to maintain their type definitions in their project repo. Because it is easier to fix the wrong type definitions. Web3 decide to remove it which is a sad decision for me. In my opinion, the gap between web3 and the web3 type definitions is really hard to fill up because of the type separation to the other repo, the fast speed of the web3.js development and the size of web3js project. Many typescript developers do not like/agree about the central repo about type definitions like as DefinitelyTyped because of the reasons.

Lastly, the bad types. I can tell it bad. It has not correct type parameters number/types, typos and not clear dependencies directions in the README. It is very basic and small things which can be fixed very easily. I know I should not complain about it because you guys mentioned, """Please note: We do not support TypeScript ourselves. If you have any issue with TypeScript and web3.js do not create an issue here. Go over to DefinitelyTyped and do it there.""". Okay, I got it. However, just one thing point out. You might need to install type definitions for bignumber.js and lodash too. bignumber.js or bn.js? underscore or lodash? which one is right? please let me clear.

[zlumer]

@donamk PR is the right thing to do, thank you. I can't talk for @levino here, but I can understand his feelings. We can't force library developers to use TypeScript, neither can we force them to add and maintain typings. That's why DefinitelyTyped initiative was started and became defacto standard.
This may not be perfect, but at least it works for now. @levino himself invested a lot of work to make typings up to date and available by standard yarn add @types/web3, it's really not fair to blame him for problems when he was the one fixing them while (almost) nobody else cared.
We still have a long way to go with these typings, and it will be much more constructive if everyone just submitted a PR with fixes to whatever bugs they find.

[levino]

These awful things happen very easily if the main repo does not include type definitions.

For what I understand you come here, find a bug and start immediatly challenging a well established, de facto standard way of handling things. This was discussed and it is written all over the internet as a best practice pattern: If your library is not written in typescript, do not maintain typescript definitions yourself, do it at DT. This also has nothing to do with the bug you found because this bug existed before the definitions were migrated from web3 to DT.

The baseline is this: Please exercise humility and and modesty. Try to understand what is going on before pointing fingers and declaring that "you found a general problem in the overall setup". If all others are ghost drivers, it is probably not them who are the problem.

Your PR suffers from the same absolutism. You are basically "redesigning" the codebase with a chainsaw. There is no need to change everything to fix your bug. I am actually wondering what your bug exactly is, so I invite you to first create some issues that describe the problems you encounter (fill out the templates! All of them! This is more important than your code change! Make it easy for us to follow your thoughts.). Then - after I agree that there is a bug that is worth fixing - I will review a carefully written pull request, addressing the bug (and only the bug), adding some regression tests and which has a fully and detailed filled out template for the PR description. I would never submit such a sloppy PR to an open source project and expect people to spend their time reverse engineering what I could have intended with my code changes. It is just an annoyance.

The fact that your PR does not even pass the build prevents me from spending any time on it at the moment. Once the build passes, I will start talking about the missing issue, then about the PR description and only then about the code changes.

[donamk]

@zlumer Thank you for your advice :)

I am not blaming @levino or his code. If you feel like that, I am sincerely sorry @levino . I think to put your code on the same line to yourself is a bad thing. Even a very good programmer can make a bug. Also, I think pointing the broken code out is not a bad thing. A person points out and the other person can fix it. What's wrong with the approach? Please open your mind, blame the code does not means/equal to blame the developer.

I already knew that what Typescript recommend. The de facto standard might not be a best practice for all projects. Of course, it can be the best for most of the project. There is no silver bullet. I will not argue anymore about it. I understand that what web3js community decide it. In many cases, better things come out because some people do not agree with it. Definitely, it is not the proper place to talk about it. I will go to typescript repo and start to talk about this.