Web3 typescript definition has no default export

[nicolaslawdune]

Hello,

Web3 Typescript definition on branch 1.0 doesn't contain "default export".

Context

• Typescript version : 2.6.2
• Converting ES2015(ES6) to ES5

After importing :
import Web3 from 'web3';

Compilation Error

Module '"xxxx/node_modules/web3/index"' has no default export.

Update 1

After importing like this import Web3 = require('web3'); I got a compilation error :

error TS1202: Import assignment cannot be used when targeting ECMAScript modules. Consider using 'import * as ns from "mod"', 'import {a} from "mod"', 'import d from
"mod"', or another module format instead.

This error is due to Module mode from tsconfig which is ES6.

Update 2

I remove module mode from tsconfig and it works now.

[matrushka]

Have you seen #1184 ?

[connectdotz]

the type definition reflects the current module implementation line 78

module.exports = Web3;

Based on typescript document, it is recommended to adopt module-class, which is why the type is exposed with "=" and not default.

We have been going back and forth on this issue as you can see with #1184, which was exactly to undo the default import that undo the "=" earlier... I am sure we don't want to keep repeating this cycle, will the following import syntax work for you?

import Web3 = require("web3")

[nicolaslawdune]

Using "require" keyword, I got this error on compilation (module: ES6 and target: ES5)

error TS1202: Import assignment cannot be used when targeting ECMAScript modules. Consider using 'import * as ns from "mod"', 'import {a} from "mod"', 'import d from
"mod"', or another module format instead.

[connectdotz]

web3.js is still using es5 module system, so it's best to use the compiler option that supports it... try module: "commonjs"

[kespeart]

Doing import Web3 from 'web3' works for me in version 1.0.0-beta.26 but when i upgrade to 1.0.0-beta.27 I receive the error mentioned in this post.

I could use the lower version but i noticed that the method for viewing pass events, which is what i want to do, has changed in .27. In version *.26 the passed events can be viewed by invoking getPastLogs(*) but in *.27 you have to call getPastEvents(*);

Please resolve soon, thanks

[kespeart]

seems like @nicolaslawdune has a PR for this

[connectdotz]

here is the bottom line:

• export = works for module:"commonjs" but breaks module:"es6"
• export default works for module:"es6" but breaks module:"commonjs"

If you guys look at the commit history, you can see that we have tried both export styles multiple times because every time you switch to one the other camp complained. Giving the module can't be exported both "=" and "default", we have to choose one...

but which one? I think we all agree that the type definition should closely reflect the original package implementation: current web3's js implementation uses "export =", according to typescript official doc, it is recommended to adopt type definition with "export =" (see here). This tips the scale for export =.

[hodlbank]

PR1249 made it "export default" again in version 1.0.0-beta.30 . Doesn't work with commonjs anymore.

[macbem]

Just use ES Modules since it's JavaScript's official module system and stop changing it all the time. It's a breaking change and breaking changes are never welcome.

[AlexBeauchemin]

What I ended up doing to stop typescript from complaining and still have type definition and autocompletion is

import * as W3 from 'web3';
const Web3 = require('web3'); // tslint:disable-line

const web3: W3.default = new Web3(new Web3.providers.HttpProvider('http://localhost:8545'));
const balance = await web3.eth.getBalance('0x...');
...

[rraina]

@AlexBeauchemin was able to make it work as follows:

import W3 from 'web3';

export const network = 'XXX';
export const web3: W3 = new W3(new W3.providers.HttpProvider(network));

[nivida]

This should be fixed with the PR #2000 thanks to @joshstevens19 who is writing the typings!

[levino]

@nivida Which typings are you talking about?

[nivida]

@levino He has currently just implemented the typings for web-utils and there is an open PR for web3-bzz maybe you can help him or move the typings from DefinitelyTyped into the web3.js repository. I would like to have them directly in the repository because this way I can guarantee that they are always up to date. The issue above should be fixed because of the refactoring and the typings Josh is writing but I will proof it before I merge the PR into the 1.0 branch.

[levino]

I repeatedly said and it is best practice to only have the type definitions at definitely typed. You should never again bring type definitions back into this very code base right here. The only exception for this rule is, if you actually write the code in typescript.

[joshstevens19]

@levino Hey dude, I have to say I completely disagree. I do agree types say quote If you are the library author and your package is written in TypeScript, bundle the autogenerated declaration files in your package instead of publishing to DefinitelyTyped. - but this would work in a standard js project.

At the moment the typing's NEVER get kept in date, someone does a PR in web3.js and you can not force them to do another PR in @types/web3. This then causes a huge knock effect for all the typescript devs when new versions are released as the types just do not match up. I have had this about 40 times and only finding out the types are incorrect by having to write full unit tests (I am sure a lot of other ts developers has had the same experience).

If it was actually in the repo itself you can enforce contribution instruction to make sure the typing keep in date all the time. I seen other repos like BigNumber -(https://github.com/MikeMcl/bignumber.js/blob/master/bignumber.d.ts) do this due to how impossible it was to manage it being in 2 separate repos.

At the current time the web3-utils are out of sync in the @types lib, i have not checked the others but the entire development experience trying to work in ts with web3 is too hard at the moment due to the amount of changes. As the main developers work in js ts is 2nd thought and it should be part of the entire development structure while writing new things in web3 itself. We should also be able to release types + web3.js at the same time at the moment we have to wait for the @types PR to be approved which is out of our control.

This solution will mean updating methods in the future and updating it's typing will be super easy for all the maintainers as it's in 1 repo. It will also mean the typing's will never be out of sync due to contribution guidelines but still versioned nicely. I know a lot of people may just use js but as a regular TS developer using these library i believe this would be a very good way to start improving this, and a lot of the people i have spoken to about this have agreed.

I just trying to make this seamless, bringing easier development for the TypeScript devs that's all. Like i said i can tell you a thousands times where the types reflected are so out of date. This would solve a lot of issues i see raised with typing's and bring it all in with 1 install command.

This does no harm to any js developers or ts developers (their experience is still the same) I only see it bringing positives mainly for stability of the code. If you have any negatives you see in doing it this way I would love to hear it though ?

Let me know your thoughts :)
Thanks
👍

[levino]

I removed the type defintions after a long discussion because they were broken (as in "You were not able to use web3 in a typescript project without monkey patching the broken type defs, shipped with web3) They were broken because there are no automated tests for the type definitions in this repo here. There cannot be. Definitely typed has such tests. I agree that it is a slow process but the process you are suggesting will make things even worse: Everyone who is making a contribution to web3 will have to be a typescript pro from now on. Because as you are saying you will reject every PR without an update to the type defs. At the same time you do not even code the library in typescript! So I have to live with the sadness that I have to write my contributions in JS and then I have to type them by hand afterwards. What a clusterf**k.

There are two possible and acceptable ways to proceed:

1. When the API has changed, make a PR to DT fast and live with the fact that sometimes the type defs are outdated for a couple of days. Also stop making big changes to the API.
2. Start writing the code in typescript (which can be done incrementally) and autogenerate the type defiintions.

All other approaches are going to fail and only cause misery.

[levino]

One other thought to keep in mind: This library is written in Javascript, because the people contributing to it are not able to write Typescript code. If they were, the library would be written in Typescript. Now you want them to review type definitions for a usage of this library in Typescript projects. You see the problem?

[joshstevens19]

Thanks for your quick response @levino. I completely understand what you are saying.

Everyone who is making a contribution to web3 will have to be a typescript pro from now on - I disagree to declare types is easy and if we add some instruction to do so then we can make it simple for them. If they did not update the types again you are in the situation where you have broken types, so the experience is rubbish for ts devs.

So I have to live with the sadness that I have to write my contributions in JS and then I have to type them by hand afterwards - That is the case now though, contribute in JS and then contribute to @types in typescript so that doesn't change here. (we should be making this a mandatory thing!!)

I think this would be a step in the correct direction and maybe in the future web3 will be full ts code. There is no negatives to putting them in web3 directly, i see no technical negative issues. The things you stated are the case right now with people having to contribute in js and write types in ts.

Not sure how it will cause misery either? If we promote a approach of updating both i think the community would be fine with this. It will actually cause a better developer experience for people who install it. web3 has 10 contributes with more then 4 commits so I don't see this being a killer here. The main advantages will come from the people using it (which is a lot more then 10 people).

This will add a little bit more work for the contributors but make the whole experience better for everyone downloading it and using it in projects as the types will always be correct.

This library is written in Javascript, because the people contributing to it are not able to write Typescript code. - I think any js can write standard type definitions with a little bit of support, even if this is fixed by someone who could again i can't see it being a problem. Like i said we don't have loads of regular contributors anyway.

[levino]

And one more thing: PRs to DT get merged pretty quickly when they are good. Most of them aren't though.

[levino]

This library is written in Javascript, because the people contributing to it are not able to write Typescript code.

I think any js can write standard type definitions with a little bit of support, even if this fixed by someone who could again i can't see it being a problem. Like i said we don't have loads of regular contributors anyway.

This is a false assumption. First you code javascript. Then you code typescript. Then you learn how to produce type definitions. Devs who are able to write type defintions are a subset of the devs who have mastered Typescript, not the other way round. This is an opinion of mine and we reached a point were we have two different opinions and I have not further arguments to give. I made my point.

Tipp

[joshstevens19]

@levino but we have under 10 regular contributors.. do you not think this would bring more good then bad? Say yes some js need some support with types but with not many people actually contributing this should not be that hard to maintain. The main advantages it brings are huge over the valid points you have stated. For the over 200k weekly downloads web3 gets I think this could solve a lot of ts pains they have.

This could be the first step and maybe in the future web3 is rewritten into ts but we have to start somewhere.

Thanks a lot for your view and taking time to discuss!

[levino]

I get your argument: These 10 contributors should be able to learn typescript. I disagree with your conclusion: Lets make them learn typescript and then maintain the type definitions for this JS code base. I think the only conclusion can be: Lets make them learn typescript and write everything in typescript. With allowimplicitany you can just rename every file to .ts and be done. Project is now in typscript.

[joshstevens19]

I think some other milestones have to be reached first before this gets done like actually release of 1.0.x none beta. I am a big supporter of getting web3 in ts and would happily go through the entire thing and change everything to ts but i think that's a bigger discussion to have.

Really appreciate your view though!
Cheers Levin 👍

[levino]

And one thing about the argument with BigNumber.js: The pain you experienced was not because the type defs where maintained in another repository, but because bignumber.js is not written in typescript.

[macbem]

A popular example of a lib that's not written in TS and maintains its own type defs is Redux - it seems to work fine for them. Redux is way simpler than web3.js, but it also has way more contributors and downloads than web3.js.

[levino]

That might be. But it is against best practice and I explained in detail why the categorical imperative says it is a bad idea. Only because some people do it does not mean that we have to do it too.

[macbem]

Who defined the best practice you're talking about? One of the most important libs in the industry does it differently without problems, so I don't really see how it's against "best practice". TypeScript docs don't discourage such approach either, so I think that it's just your opinion and not a sacred truth that we should follow.

I've used web3.js with TypeScript and each time I've written my own typings for things I needed, because the official ones were just plain wrong and not helpful at all. Bigger Ethereum projects like 0x also have picked this route (as seen here) to avoid the hassle of working with official web3 typings from DefinitelyTyped.

[joshstevens19]

Let others maintain and publish the definitions iff your package is not written in typescript. - With this view we will never ever have solid types for web3 so ts development with it becomes unstable or having to use any everywhere 👎 The likes of Redux do this because of the pain it causes relying on others to maintain the types, and as @macbem said they have far more contributors and over 2 million downloads a week, we should learn from people who have gone through the pains.

We are in a world where ts development is taking over so i thought web3 would start adopting to supporting in-house types. This would of been a great start. Again i see no reasons that you stated which makes it technical bad, in my view the positives overweight the negatives by far. If web3 do not support ts out the box people will have to start using other libs which do which i would hate.

Anyway discussion over - see ya!

[macbem]

@joshstevens19 I'd suggest locking this thread to avoid further flamewars.

[levino]

Who defined the best practice you're talking about? One of the most important libs in the industry does it differently without problems, so I don't really see how it's against "best practice". TypeScript docs don't discourage such approach either, so I think that it's just your opinion and not a sacred truth that we should follow.

Please read the docs more carefully. I quote (again and again and again):

Now that you have authored a declaration file following the steps of this guide, it is time to publish it to npm. There are two main ways you can publish your declaration files to npm:

1. bundling with your npm package, or
2. publishing to the @types organization on npm.

If your package is written in TypeScript then the first approach is favored. Use the --declaration flag to generate declaration files. This way, your declarations and JavaScript always be in sync.

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

[treeder]

@levino not trying to pick sides here, but you must agree that breaking web3.js for typescript users on a regular basis is not a good thing? Regardless of what the TypeScrypt docs say. For better or worse, a lot of people are using TypeScript that also use web3.js.

It sounds to me like the only option here to prevent the regular breakage is to include the ts file in this repo so it's always in sync. If the contributors to this repo don't want to update the types file, let some of the people on this thread help whenever a PR comes in to ensure it gets updated properly before merging, it would probably only take a few minutes of a "TypeScript pros" time to check the types file for each PR.

[levino]

You all want to have typings that are up to date with the current interface of the library, right? Guess what: There is only one (just one!) way to achieve this: Implement the library in typescript and generate the typings automatically.

Even if you maintain the typings here, they will be out of sync all the time. As I said, the typings in this repo were broken. There are several reasons why this cannot work:

1. Pull request reviewers do not understand typescript and cannot review whether or not the changes to the typings are correct.

2. The typings will not be tested. So even if the reviewer is a typescript pro, they are human and will overlook things. (DT tests all typings automatically in CI!!!!)

3. Someone makes a really nice pull request. It gets merged because javascript users want the new feature. Nobody cares for the update to the type definitions because the contributor with the pull request is not able to write them and nobody else comes to the rescue in time.

4. and 3. is the same for DT, but 3 is not. You will not achieve what you are looking for when you maintain the typings here. Also who of you has made a contribution to DT? It is super easy. There is nothing to fear. The review process is heavliy streamlined and fully automated.

So my point is: You all push for maintaining the typings here but you will not achieve what you want to achieve. The type definitions will be out of sync all the time not matter what until this is rewritten in typescript.

[levino]

Unfortunately in the typescript docs they do not explain why you should publish the typings via DT when you write your package in Javascript, but I think I gave enough reasoning. Additionally to that: Why do you think that they recommend that?

[nivida]

Pull request reviewers do not understand typescript and cannot review whether or not the changes to the typings are correct.

I think I do understand TS it is not that rocket science thing to do types.

The typings will not be tested. So even if the reviewer is a typescript pro, they are human and will overlook things.

Maybe we could test them in our CI too.

Nobody cares for the update to the type definitions because the contributor with the pull request is not able to write them and nobody else comes to the rescue in time.

This should not happen if I review a PR.

Why do you think that they recommend that?

I think you should answer this question :)

[levino]

Pull request reviewers do not understand typescript and cannot review whether or not the changes to the typings are correct.

I think I do understand TS it is not that rocket science thing to do types.

So you will from now on personally review all PRs? That is going to scale well.

The typings will not be tested. So even if the reviewer is a typescript pro, they are human and will overlook things.

Maybe we could test them in our CI too.

Yes. That is quite easy. What is more easy though is to rewrite the whole codebase in typescript.

Nobody cares for the update to the type definitions because the contributor with the pull request is not able to write them and nobody else comes to the rescue in time.

This should not happen if I review a PR.

It will happen. Or you will drive away open source contributors because they create a valid PR which never gets merged because "we are still waiting for the typings".

Why do you think that they recommend that?

I think you should answer this question :)

I did explain my thinking. Three times. I repeat myself. People say that I am not right. I want to here their train of thoughts.

[levino]

And another question for you all: What about flow? Should we add flow typings too? Facebook is using flow!

[nivida]

So you will from now on personally review all PRs? That is going to scale well.

Yes thats what I'm doing currently and will do as long as I work for this lib.

Yes. That is quite easy. What is more easy though is to rewrite the whole codebase in typescript

I think we can test them with for example https://github.com/Microsoft/dtslint

It will happen. Or you will drive away open source contributors because they create a valid PR which never gets merged because "we are still waiting for the typings".

Then I have to write the types by my self and I think that will not happen so often.

I did explain my thinking. Three times. I repeat myself. People say that I am not right. I want to here their train of thoughts.

No you didn't you were just quoting the TS documenation but you never really explained the thoughts behind it. The TS documentation does not explain it either.

And another question for you all: What about flow? Should we add flow typings too? Facebook is using flow!

I think I could add for example this: https://github.com/joarwilk/flowgen to the publish process to generate them. Idk how good this is but maybe that could be a solution.

I'm not saying that I like one of the solutions more then the other but until now I can't see a reall killer argument that we should have them on DT. I think thats more an ethical thing. 😅

[joshstevens19]

I really am trying to find it hard to understand why you are so passionate in not having them in the web3 lib itself.

We do not have many contributors as it is and we can make sure its part of the contribution guidelines. I am sure a few types is not going to make people fear or stop contributing at all, does that stop all of 500 contributors to Redux?

We can also make sure it's tested in our CLI so its just as good and safe as DT.

"It will happen. Or you will drive away open source contributors because they create a valid PR which never gets merged because "we are still waiting for the typings". - That is the correct approach in my view. We should be able to support stable ts developers as well as js developers, with web3 maturing we need to be in control of this. We shouldn't be able to release a new version of web3 and the types not match up, we can't continue like that.

As i keep saying Redux do this due to making it a lot nicer for the developers to just install and do it, they also have full control on what goes into it! They can then make sure no dodgy invalid types are going into the types file. I have seen in a few PR in DT that the change got automatically approved which was a breaking change type and after a while it just goes into the branch 👎 that is super scary.

"Pull request reviewers do not understand typescript and cannot review whether or not the changes to the typings are correct." - Come on now, are you really saying js developers can't understand

export default function blah(x: string): string ???

We are at a point where ts developers do not trust the web3 typing's and in that sense makes them have to use any everywhere or create their own - which is shocking from a development point of view. People should be able to just install and go. Having it in here technically creates no problem.. you have not stated 1 valid technical view in how this is a bad thing. Your only point is "js developers can't understand ts and therefore should not have to" - which is not true and "contributors won't like it".

"So my point is: You all push for maintaining the typings here but you will not achieve what you want to achieve. The type definitions will be out of sync all the time not matter what until this is rewritten in typescript." - how is that true? if we are strict on the PR then we will always have valid types.

We need to be making this stuff mandatory like Redux do, allowing web3 to be supported and stable in both ts land and js land.

TypeScript don't explicitly say you should do it this way they say preferred approach. But like i keep mentioning Redux have gone down this path and their code base has loads of contributors all forced to do types and all js developers + a very stable and widely used library :)

[levino]

Just do what you want if you do not want to listen to reason. This is going to be a fuckup! At least I told you so.

[joshstevens19]

oh and moment has their own types and it's a JS project

https://github.com/moment/moment/blob/develop/moment.d.ts

are moment and Redux both a "fuckup"? @levino I have stated valid points here.. you have not really replied to any of them. 👍

[levino]

I understand your argumentation. You will from now on review every pull request and your super powers will make sure that every change to the API of the library or any of the sub-packages will be reflected 100% in the typings here in the repo. I say: You will fail! And you say: No I have my superpowers. Which is fine. But I will not waste more time on this. Do it then. It will be painful and hard and you will fail. Lets talk again in a year.

[levino]

And btw: If at some point you decide to rewrite the whole codebase in TS, that does not count as a success, but a fail too, right? Because that is what you want to avoid with your approach.

[levino]

Ah and I forgot to predict something: You will have hundreds of issues from Windows-using script kiddies who cannot use Typescript right but will blame you for "incorrect typings". They will all go on the backlog and jam it.

[treeder]

Ah and I forgot to predict something: You will have hundreds of issues from Windows-using script kiddies who cannot use Typescript right but will blame you for "incorrect typings".

This is already happening @levino , this is what this discussion is all about. Apparently all of us TypeScript users are "script kiddies" and yes, we're complaining about this library breaking every time you update it. If you want us "script kiddies" to stop complaining, then just do the right thing and fix the problem. You have a bunch of people saying they'll even help fix the problem, which you don't seem to want to accept. 🤦‍♂️

[levino]

I maintain (with others of course) the @types/web3 package. If the maintainers of web3 would drop typescript support, they could just close every typescript related issue and save time and money.

And I repeat: If you all want that this library supports typescript itself, then JUST WRITE IT IN TYPESCRIPT!

[Asone]

Well, i've been having this page opened for the whole afternoon and i must admit i'm quite amazed by how this has gone to some flames.

As JS & TS developper, in normal times, i would have been supporting separated repo for providing types, as requested by @levino, as i rather prefer avoiding to have any broken type provided by the original repo, third-party packages being easy to remove without touching web3 original code.

However, as i read the answers it seems quite technically feasible to ensure types are correctly written before merging any PR, as @nivida provided tools & examples of others projects doing so.

Comment from @jpeletier here : #1302 (comment) also makes me think that rewriting web3 into a TS form might be quite faster as it could be expected.

If web3 dev team commits to review type definitions while a typescript migration is being built, i'll definitely support it, they made their point.

If at some point you decide to rewrite the whole codebase in TS, that does not count as a success, but a fail too, right?

@levino : i don't think it's about winning or failing here but rather having a collective conversation about how to do it the best way possible. Too bad to have thrown useless flames for that. In any case, and still, thanks for providing @types/web3. Much datalove

[joshstevens19]

@levino I think people who do this like moment and redux are doing just fine with this approach. Big repos with millions of downloads a day do this and succeed without superpowers 😃

Ah and I forgot to predict something: You will have hundreds of issues from Windows-using script kiddies who cannot use Typescript right but will blame you for "incorrect typings". They will all go on the backlog and jam it. - With good contribution guidelines and standard check this will be avoided + this is far better then updating the types and all of a sudden it breaks your ts project when you upgrade web3 👍. Any type issues will be added as issue in web3 which will be fine, i'm sure we can handle all these so called script kiddies ha ha!! 👍

I maintain (with others of course) the @types/web3 package. Ahhh the penny has dropped in why your so passionate about this now 😂

Very open to rewrite it in ts which is on the cards in the future for now the main focus is getting web3 beta live with support for all ts js developers, then web3 in ts will come 😄. @nivida will have a roadmap for this.

Thanks for the good discussion though @levino i do respect your views and no hard feelings 👍

[levino]

If everybody here speaks Typescript then there is no reason not to write this library in Typescript.

I repeat again: One can incrementally migrate a library to typescript. But that requires some Typescript skills.

[nivida]

I will lock this issue now because I think we already seen all the arguments.
Thanks everyone for the effort to be a part of this discussion!

[nivida]

The usage of Web3.js with TypeScript is explained in the root README.md of the 2.x and 1.x branch.