[Snyk] Upgrade web3 from 1.0.0-beta.37 to 1.2.6 #2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Snyk has created this PR to upgrade web3 from 1.0.0-beta.37 to 1.2.6.
ℹ️ Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.The recommended version fixes:
SNYK-JS-TAR-174125
SNYK-JS-FSTREAM-174725
SNYK-JS-DECOMPRESS-557358
Release notes
Package name: web3
This release does update the ENS registry address in the web3.js library.
Added
Changed
This release does add the
requestAccounts
,getPendingTransactions
, andgetProof
JSON-RPC method. By side of it does it improve the returnedError
object on the failure of a transaction and provides the possibility to activate the revert instruction handling with the newly addedhandleRevert
module option.Added
eth_requestAccounts
asrequestAccounts
added to web3-eth package (#3219)sha3Raw
andsoliditySha3Raw
added to web3-utils package (#3226)eth_getProof
asgetProof
added to web3-eth package (#3220)BN
andBigNumber
objects are now supported by theabi.encodeParameter(s)
method (#3238)getPendingTransactions
added to web3-eth package (#3239)handleRevert
module property (#3248)receipt
does now exist as property on the error object for transaction related errors (#3259)internalType
added toAbiInput
TS interface inweb3-utils
(#3279)HttpProvider
options (#2980)Changed
eth-lib
dependency updated (0.2.7 => ^0.2.8) (#3242)Fixed
defaultBlock
property handling fixed (#3247)clearSubscriptions
does no longer throw an error if no running subscriptions do exist (#3246)Accounts.signTransaction
fixed (#3280)This is a release candidate for version 1.2.5 of web3.js
The changelog of it can be seen here #3315
This release is a hotfix for the scrypt-shim and websocket dependency.
Fixed
We have improved with this release the TypeScript type definitions, we applied a fix for the OOG (out-of-gas) error issue, and we added a missing polyfill to the web3.min.js file.
Fixed
TypeScript
We have back-ported all the types from 2.x to 1.x and do now provide the type definitions directly from the web3 repository. (Docs)
Thanks Josh Stevens for back-porting them for us!
Signing
We have improved the signing process and updated it to the latest version of
ethereumjs-tx
. This update brought up some newly required configuration properties for custom chains.These new
TransactionConfig
config properties do also have the related default properties on theweb3-eth
andweb3-eth-contract
module:Transaction Confirmation Workflow
We updated the confirmation workflow for the
HttpProvider
. A confirmation will now only get triggered if a new block is existing and not each second.Additionally is it now possible to configure the confirmation workflow with the following default properties on the
web3-eth
andweb3-eth-contract
module:New JSON-RPC Method
We added the JSON-RPC method
eth_chainId
asgetChainId
method on theweb3-eth
module.The documentation for this method can be found here.
New utility Functions: Bloom-Filters
What are bloom filters?
A Bloom filter is a probabilistic, space-efficient data structure used for fast checks of set membership. That probably doesn’t mean much to you yet, and so let’s explore how bloom filters might be used.
Imagine that we have some large set of data, and we want to be able to quickly test if some element is currently in that set. The naive way of checking might be to query the set to see if our element is in there. That’s probably fine if our data set is relatively small. Unfortunately, if our data set is really big, this search might take a while. Luckily, we have tricks to speed things up in the Ethereum world!
A bloom-filter is one of these tricks. The basic idea behind the Bloom filter is to hash each new element that goes into the data set, take certain bits from this hash, and then use those bits to fill in parts of a fixed-size bit array (e.g. set certain bits to 1). This bit array is called a bloom filter.
Later, when we want to check if an element is in the set, we simply hash the element and check that the right bits are in the bloom filter. If at least one of the bits is 0, then the element definitely isn’t in our data set! If all of the bits are 1, then the element might be in the data set, but we need to actually query the database to be sure. So we might have false positives, but we’ll never have false negatives. This can greatly reduce the number of database queries we have to make.
Bloom filters benefits with a real-life example
An Ethereum real-life example in where this is useful is if you want to update a user's balance on every new block so it stays as close to real-time as possible. Without using a bloom filter on every new block you would have to force the balances even if that user may not have had any activity within that block. But if you use the logBlooms from the block you can test the bloom filter against the users Ethereum address before you do any more slow operations, this will dramatically decrease the number of calls you do as you will only be doing those extra operations if that Ethereum address is within that block (minus the false positives outcome which will be negligible). This will be highly performant for your app.
Added Functions:
Thanks Josh Stevens for adding these functions!
Subscription Events
We extended the subscription events with a
connected
event. Theconnected
event will emit the subscription ID as a hex value when the subscription got established. This applies toContract
events as well.Example:
Providers
We extend the provider interface with the method
supportsSubscription
. This will help the DApp developers to detect if thecurrentProvider
does support subscriptions.Changelog
Added
eth.getChainId
method (#3113)connected
event on subscription creation (#3028)Fixed
0
as a validfromBlock
ortoBlock
filter param (#1100)null
(#2183)net_version
when signing txs (#2378)tx
object passed to functionsignTransaction
(#2190)This release contains several stability improvements.
Fixed
websocket
dependency fixed (#2971, #2976)requestOptions
added toWebsocketProvider
(#2979)Thanks for providing these fixes @michaelsbradleyjr.
We decided jointly with the open-source community to release the older architecture (1.0.0-beta.37) as 1.x version of web3.js. Further details are explained in the following Medium blog post.
Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs