v4.0.1-alpha.2

[spacesailor24]

Added

web3-eth-contract

• Decoding error data, using Error ABI if available, if error was returned from a smart contract function call (Use Error ABI to parse errors when sending a transaction #5662).

web3-types

• These types were moved from web3-eth-accounts to web3-types package: Cipher, CipherOptions, ScryptParams, PBKDF2SHA256Params, KeyStore (Update wallet.encrypt function signature 4.x #5581 )

web3-utils

• Export a new function uuidV4 that generates a random v4 Uuid (Responses get mixed up due to conflicting payload IDs (v 4.x) #5373).
• Enable passing a starting number, to increment based on it, for the Json Rpc Request id (Test with injected external providers #5652).
• Export a new function isPromise that checks if an object is a promise (Test with injected external providers #5652).

web3-eth-contract

• SpecialOutput type was added as a generic type into the call function to support reassigning output types (Documentation for catching provider events #5631)
• Overloaded functions types (ContractOverloadedMethodInputs, ContractOverloadedMethodOutputs) was added (Documentation for catching provider events #5631)

Fixed

web3-eth-contract

• Emit past contract events based on fromBlock when passed to contract.events.someEventName (Contract events does not support fromBlock property #5201)
• Use different types for ContractOptions -> jsonInterface setter and getter (Change contract.options.jsonInterface - ts issue #5474)
• An issue within the Contract constructor where provider wasn't being set when provided within the optionsOrContextOrReturnFormat argument (Remove erroneous set provider code for Contract constructor #5669)

web3-types

• Make the request method of EIP1193Provider class, compatible with EIP 1193 ([4.x] Transaction sending does not work with Ganache's EthereumProvider #5591)

web3-utils

• Use Uuid for the response id, to fix the issue "Responses get mixed up due to conflicting payload IDs" (Responses get mixed up due to conflicting payload IDs (v 4.x) #5373).

web3-validator

• Fix isHexreturning false for -123, fix isHexStrict returning true for -0x, and fix isHex returning true for empty strings `` (Responses get mixed up due to conflicting payload IDs (v 4.x) #5373).

web3-eth-abi

• Fix ContractMethodOutputParameters type to support output object types by index and string key. Also, it returns void if ABI doesn't have outputs and returns exactly one type if the output array has only one element. (Documentation for catching provider events #5631)

Removed

web3-eth-accounts

• These types were moved from web3-eth-accounts to web3-types package: Cipher, CipherOptions, ScryptParams, PBKDF2SHA256Params, KeyStore (Update wallet.encrypt function signature 4.x #5581 )

[render]

Your Render PR Server URL is https://atweb3js-docs-pr-5664.onrender.com.

Follow its progress at https://dashboard.render.com/static/srv-ce3a2dpgp3jqhjti41a0.

[avkos]

@spacesailor24 thanks for PR. just need to merge 4.x into this branch and resolve conflicts.

[spacesailor24]

@spacesailor24 thanks for PR. just need to merge 4.x into this branch and resolve conflicts.

@avkos So usually we would have an RC version we could bump every time we make changes to the release since the last commit in the release is tagged with the version. We've already messed up by merging #5689 into this branch, since now the branch has commits that come after the tagged commit. This isn't a huge issue since this only really affects the continuity of the release listed in Github (I'm talking about the Assets listed in the release). I believe the right steps would've been to open a PR that merges 4.x into the release branch to solve the conflicts and cut another RC, but we don't have that option now since there are no RC versions for 4.x yet

So, if we are to merge 4.x into the release branch and solve the conflicts, we'd need to re-build all the packages, commit, tag the commit, and re-create the release on Github

[jdevcs]

@spacesailor24 thanks for PR. just need to merge 4.x into this branch and resolve conflicts.

@avkos So usually we would have an RC version we could bump every time we make changes to the release since the last commit in the release is tagged with the version. We've already messed up by merging #5689 into this branch, since now the branch has commits that come after the tagged commit. This isn't a huge issue since this only really affects the continuity of the release listed in Github (I'm talking about the Assets listed in the release). I believe the right steps would've been to open a PR that merges 4.x into the release branch to solve the conflicts and cut another RC, but we don't have that option now since there are no RC versions for 4.x yet

So, if we are to merge 4.x into the release branch and solve the conflicts, we'd need to re-build all the packages, commit, tag the commit, and re-create the release on Github

In case of merge conflicts, and before actual release, could you go ahead with following:
Merge main branch into release PR, build, delete old tag, recreate new tag, and re populate github draft release with newly created tag. There isn't any technical limitation or issue in that, if it happens before release on npm / github.

In future we should also follow freezing main branch for 4.x if there is release PR created, we were following this in 1.x.