-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal to stabilize Web3 1.x #3070
Comments
Hey nice, I can't see many of the PRs for the new typings which we spent a lot of time on and it works perfectly in TS projects now. This matches the same interface as 1.0 as that did not change so we should get them in in my view: #2844 #2645 #2618 #2550 #2516 #2471 #2422 #2417 #2416 #2415 #2336 #2322 #2288 #2280 #2278 #2262 #2261 #2253 #2231 #2219 #2218 #2217 #2203 #2134 #2133 #2128 #2125 #2123 #2122 #2121 #2119 #2118 #2114 #2113 #2112 #2096 #2090 #2084 #2078 #2073 #2056 #2753 #2672 #2643 #2619 #2585 #2575 #2557 #2556 #2529 #2479 #2478 #2355 #2233 |
I wrote a quick script to format the raw lists provided by @alcuadrado and @joshstevens19 into a list of checkboxes with issue titles: (list moved to issue description) I also started a GH project here to triage/organize the effort. Hope these help! |
Happy to back-port every PR I put in my comment into 1.0 if you wanted a extra pair of hands. Let me know. |
I have gone though these in a first pass and sorted them a little. Have also opened a handful of PRs back-porting small fixes. My general impression is that many of the remaining things to fix are edge cases for which there are well-documented work-arounds in the issues or typescript related. I've also marked a number of items as needing "E2E" - by which I mean: to safely fix these we should test vs a client, or validate against downstream project. #3098 contains some ideas about how to do that. . . One way forward is to take a small detour and set CI up so that things can be addressed with greater certainty about what the consequence of a given change might be. WDYT? |
@cgewecke Let us discuss the e2e stuff in the related issue :) @joshstevens19 I've added the types PRs above. |
Nice to see that collaboration, makes my heart warm 💓 |
I spent some time to find out that I have to go back to beta 37 to continue my work on my dapp. Since I am not quite familiar with node.js, I would like to ask if the pre-built binaries web3.js and web3.min.js will be included in the zip in the future. It would very much simplify one's life. |
These are going to be (or already are?) included in the |
@nivida @alcuadrado @cgewecke |
Closing. This is mostly done. |
At Nomic Labs we’ve been collaborating with the Ethereum Foundation to improve the developer experience on Ethereum, and we believe an important part of this process for the short-term is to help stabilize the web3.js library. In this document we propose a plan to move in this direction.
First, some quick context:
The versions that are widely used across the ecosystem right now are the 1.0.0-beta-37 and its subsequent 1.x releases. These releases still contain a significant amount of known bugs that have been reported, are fixed on the 2.x branch, but remain live in the versions used in production depoyments due to the releases that now exist in the 2.x branch not having significant adoption.
The fixes done on 2.x represent a ton of work that’s already been done, and it would be great if it were repackaged in a form that is usable on the web3.js deployments across the ecosystem.
We’ve gone through all the releases between 1.0.0-beta-38 and 1.0.0-beta-55 (the latest release that became the 2.x branch) and collected the list of issues that have been fixed. Thankfully @nivida has done a great job at documenting each release.
Our simple proposal consists of backporting these bug fixes from the 2.x branch to the 1.x branch, where it makes sense. We assume there may be some issues in the list that shouldn’t be included or aren’t relevant anymore.
The main objective here is stabilizing the 1.x branch, so we believe stability should be the main driver for decision making throughout this process. From our perspective this would mean, at least:
If an issue is removed from the list because of 2 or 3, it would be valuable to keep track of this.
When it comes to releases we think there should be an RC release, which teams relying on the library can test comfortably, and once any issues that arise are fixed then the proper release.
Prioritizing this list represents a difficult task to us, so we invite people with a more intimate knowledge of the codebase to highlight issues of major importance that should be included in the first release. The list is ordered in the exact same order the fixes were released on the 2.x branch, so we assume there’s been prioritization done by Samuel already. Overall, given that projects relying on the library have been a long time without a release that’s compatible with their deployments, and the work doesn’t need to be done from scratch, we think that just aiming to follow that same release order and getting them all released as soon as possible on 1.x is a reasonable approach.
When it comes to the cadence of the releases containing these fixes, we wouldn’t prioritize speed. We think that appropriately spaced releases that allow the community to properly test each release candidate is important. The objective of such a stage in each release is to identify any new issues that might have been inadvertently introduced, and fix them before moving on to the final release. Given that the amount of issues is significant (244 in the unfiltered list we collected), there should be enough time in-between each release for proper testing. We believe this is somewhere between 3 and 6 weeks between each release.
In addition, given that the 1.x branch is considered the stable release and the 2.x branch is considered the development branch, we suggest the default branch on the Github repository be set to 1.x. The rationale being to help the userbase easily access the code they’re using as a reference when needed.
We welcome any ideas and suggestions that would add to this proposal for a short-term plan to bring more stability to web3.js.
If you agree this should be the way forward, please voice your support below in the comments or with a thumbs up reaction.
These are the items on @alcuadrado's / NomicLab's original list, organized into 4 categories:
(Goal is to move everything into the
Removals with Reason
category.)@joshstevens19 has added an additional set of PRs relating to stabilizing Typescript on 1.x in a second comment below.
There's a copy of the original list here
Editors: (if you're editing, pls add your name here)
Needs investigation
Bundling / Publication
Dependencies
Security
Other
(Added back in because of recent reports that it's alive...) (cg)
Broken
Typescript
@joshstevens19 will solve all of these.
These can probably all be addressed by a single back-port PR from 2.x, after modifying
the latest types as necessary and double-checking everything makes sense.
commonjs
module #2550 docs: show how you can get the types to work in acommonjs
moduleobjects
toany
on typing's return + dtslint fix + general test fixes #2516objects
toany
on typing's return + dtslint fix + general test fixesSign
needed to have a signature on typing's + fix incorrect docs #2471Sign
needed to have a signature on typing's + fix incorrect docsAbiItem
was missinganonymous
#2422 fix:AbiItem
was missinganonymous
TransactionReceipt
typings #2416 fix:TransactionReceipt
typingsfiles
in package.json #2336 add postinstall script infiles
in package.jsonstatus
ontoTransactionReceipt
#2288 fix: addstatus
ontoTransactionReceipt
"noImplicitAny": true,
#2280 allow web3-utils to work in projects with `"noImplicitAny": true,web3-eth-personal
#2278 write missing typing forweb3-eth-personal
browser.js
to allow `{crypto: true, stream: … #2262 fix: patch the angularbrowser.js
to allow `{crypto: true, stream: …@types/node
so you do not need to add types > node in … #2219 fix: install@types/node
so you do not need to add types > node in …fromWei
andtoWei
typings #2218 fix:fromWei
andtoWei
typingssignTransaction
should returnPromise<SignedTransaction>
#2217 fix:signTransaction
should returnPromise<SignedTransaction>
web3-providers
down the tree toweb3-core
#2113 moveweb3-providers
down the tree toweb3-core
{}¬ in
bzz{}¬ in
bzzLower priority
PR Opened (back-porting...)
dist
folder andweb3.min.js
? #1041 Where is dist folder and web3.min.js?fromBlock: 0
defaults tolatest
,fromBlock: 1
works correctly ineth.getPastLogs
#1100 fromBlock: 0 defaults to latest, fromBlock: 1 works correctly in eth.getPastLogs (nv)Removals (with reason)
Duplicates
dist
folder andweb3.min.js
? #1041) (cg)dist
folder andweb3.min.js
? #1041) (cg)PromiEvent
event listeneron
confirmations
not returning correct confirmation information #2418 confirmations not returning correct confirmation information (Dup Confirmation of transaction each second #1239) (cg)returnValues
doesn't exist on event object #2265 returnValues doesn't exist on event object (Dup decodeLog() is broken after updating to beta.41 from beta.35 #2268)(cg)web3.utils.randomHex
is undefined #2270 on version 1.0.0-beta.41, randomHex is undefined (Dup web3.utils.randomHex does not produce consistent length strings #1490) (cg)dist
folder andweb3.min.js
? #1041) (cg)Wont fix
behavior at Infura in Summer/Fall of 2018 on mainnet. Issue hasn't had much traffic since then.
See comment for diagnosis and potential solution if this needs to be re-addressed. (cg)
Is fixed in 1.2.1
() =>
fns in 1.x. (cg)ecRecover
works as expected on 1.x in Clarify eth.personal.sign docs #3091 (cg)ecRecover
works as expected on 1.x in Clarify eth.personal.sign docs #3091 (cg)isBigNumber
is not available in web3-utils #2835 isBigNumber is not available in web3-utilsisBigNumber
is exported here on 1.xOnly relevant to 2.0 Branch
I've commented out the list here because the listed issues arent relevant to stabilize 1.0. (nv)I've uncommented out this list so we can see the complete survey (cg)
TypeError: callback is not a function
#2364 1.0.0-beta.46 subscribe events without callback throw exception: TypeError: callback is not a function (nv)allowSyntheticDefaultImports
is too opinionated #2382 allowSyntheticDefaultImports is too opinionated (nv)contractInstance.methods.myMethod.send
, metamask throw exception #2349 beta.43 when .send, metamask throws exception (see comment) (cg)TypeError: Cannot read property 'anonymous' of undefined
#2365 beta.46 send tx, when confirmed throw exception: (see comment) (cg)anonymousFunction()
recursively #2411 methods.call() returns anonymousFunction()recursively (see comment) (cg)The text was updated successfully, but these errors were encountered: