Fix isHex and isHexStrict for some edge cases and enrich their tests

[Muhammad-Altabba]

Description

Fixes #5616 (in addition to the added comment #5616 (comment))

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist for 1.x:

• I have selected the correct base branch.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• Any dependent changes have been merged and published in downstream modules.
• I ran npm run dtslint with success and extended the tests and types if necessary.
• I ran npm run test:cov and my test cases cover all the lines and branches of the added code.
• I ran npm run build with success.
• I have tested the built dist/web3.min.js in a browser.
• I have tested my code on the live network.
• I have checked the Deploy Preview and it looks correct.
• I have updated the CHANGELOG.md file in the root folder.

Checklist for 4.x:

• I have selected the correct 4.x base branch.
• Within the description, the feature or issue is discussed in detail or an issue is linked.
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas.
• I have added any required tests for the changes I made
• I have made corresponding changes to the documentation
• Any dependent changes have been merged and published in downstream modules.
• I ran yarn successfully
• I ran yarn lint successfully
• I ran yarn build:web successfully
• I ran yarn test:unit successfully
• I ran yarn test:integration successfully
• I ran compile:contracts successfully
• I have tested my code.
• I have updated the corresponding CHANGELOG.md file in the packages I have edited.

[render]

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

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

[spacesailor24]

In 1.x, 0x and -0x return true for both isHex and isHexStrict

---

'' also returns true for isHex in 1.x, I would consider making this breaking change (to return false instead), however I'm not sure how many of our users are relying on this behaviour

[spacesailor24]

1.x also returns false for -123 as well...

but true for 123

[luu-alex]

I think it'll be fine to stray away from these 1.x changes, as these results are a bit misleading and include these changes in the breaking changes

[spacesailor24]

@Muhammad-Altabba @luu-alex

These are the regex tests from 1.x:

isHexStrict: /^(-)?0x[0-9a-f]*$/i
isHex: ^(-0x|0x)?[0-9a-f]*$/i

Because of (-)?0x in isHexStrict check, I would assume that -123 being false and 123 being true for isHex is erroneous, and a breaking change would make sense (both should return true).

---

I'm not so sure we should make the breaking change for 0x and -0x, I think these should return true as this has the highest probability of breaking user code out of all the mentioned edge cases. As an example, even in our own code do we allow certain properties such as value, to, and input/data to be 0x:

• value being set as 0x
• data being set as 0x
• input being tested as 0x

---

Not that it matters too much, but this is what Ethers is returning

[luu-alex]

@spacesailor24 agreed, I think 0x should be okay to include but -0x probably not. If we include these breaking changes apart of the 4.x utils migration doc so that theres awareness around this for the users.

[spacesailor24]

@luu-alex Yea -0x doesn't make sense. Even if we include changes in the migration docs, it would still serve our community the best to make as little changes as possible, especially changes that might require users to make many changes across their projects (and imo, any breaking changes that involve transactions shouldn't be taken lightly)

[Muhammad-Altabba]

@spacesailor24
Actually the returned value when passing 0x to isHex and isHexStrict was never mentioned to be changed in this MR. As there is no behavior change for this case. Additionally, there is a test case added to ensure this: https://github.com/web3/web3.js/pull/5655/files#diff-d8d5a378a9499635d2f6cca11a00d76024d6a3e6afde5a6db676f824563ed75dR135 And so there is no code that would be broken for this case 😄

The only additional changes in this MR (in addition to allow accepting -123) are to fix the issues mentioned in #5616 (comment)

• both isHex and isHexStrict returns true for -0x, which does not make sense.
• isHexreturns true for empty strings ''.

However, it seems that changing the scope of this issue created some confusion, sorry for that. And also seems to better be discussed separately. So, I will revert back to the original scope (allowing -123) and we could open a different issue to discuss the other points.

---

I would like also to comment on the outputs of ether.js.
It possibly returns false for -123 by mistake because it copied that behavior from this repository (v0.x and v1.x) as it is far older 😄 . And possibly it was kept like that as this function is mostly an internal function. And for that, there were no complains also on their or this repo from any user.

And for returning false for both 0x and 0x123. From some point of view, the hex number is an abstract form of number representation that could represent any data. And so even negative numbers could be represented by something like 0xf123 for example. But also there could be someone who could write -0x456 and expect it to be a valid negative hex.
And if out try to convert -123 to Hex at: https://www.rapidtables.com/convert/number/decimal-to-hex.html it would give different values for what they called Hex number and Hex signed 2'd complement`:

For this, I did not change the behavior of returning true for -0x123. But I probably understand why ether.js returns false for that.
However, I found returning true for -0x as non-sense. But I could be wrong. And I will leave this to a possible future discussion 😄

[spacesailor24]

Okay, so I think the consensus is:

• -0x returning false
• '' returning false
• 123 and -123 returning true

[luu-alex]

im good with that,

[Muhammad-Altabba]

Okay, so I think the consensus is:

• -0x returning false
• '' returning false
• 123 and -123 returning true

Thanks @spacesailor24 . This is great if we all agree on that. As this is what is included in this MR 👍 . And so, could you, please, approve this MR, if you do not have other concerns?
If you still have some douts. It would be OK and we can discuss them here or in another issue 😄

[Muhammad-Altabba]

I think it'll be fine to stray away from these 1.x changes, as these results are a bit misleading and include these changes in the breaking changes

Thanks for the important suggestion.
Done.