chore: deprecate bech32 addresses

[maschad]

Closes TS-660

• Closes Deprecate bech32 address format #3203

Release notes

In this release, we:

• Deprecated the bech32Address type in favour of hexadecimal address format going forward.

Summary

This PR uses adds the deprecated JS-doc tag as well as makes note in the relevant documentation of the deprecation notice.

Checklist

• All changes are covered by tests (or not applicable)
• All changes are documented (or not applicable)
• I reviewed the entire PR myself (preferably, on GH UI)
• I described all Breaking Changes (or there's none)

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
create-fuels-template	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 27, 2024 5:56pm
fuels-template	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 27, 2024 5:56pm
ts-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 27, 2024 5:56pm

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
create-fuels-counter-example	⬜️ Ignored (Inspect)			Sep 27, 2024 5:56pm

[codspeed-hq]

CodSpeed Performance Report

Merging #3204 will degrade performances by 31.31%

_{Comparing mc/chore/deprecate-bech32 (f7c1009) with master (e7c2c30)}

Summary

❌ 1 regressions
✅ 20 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	master	mc/chore/deprecate-bech32	Change
❌	should successfully execute a contract mint	65.2 ms	94.9 ms	-31.31%

[Torres-ssf]

@maschad Why are we adding @deprecated to toEvmAddress, toBytes, toAssetId? These methods will continue to exist.

Also, I understand that toB256 should be deprecated, as it won't be required anymore when we drop the use of bech32. However, every @deprecated tag is recommending this method, which is also being deprecated. Isn't that misleading?

[maschad]

@maschad Why are we adding @deprecated to toEvmAddress, toBytes, toAssetId? These methods will continue to exist.

With the exception of toAssetId all of those methods all operate on the bech32 address type. Deprecating the associated methods along with the type is a good practice because:

• It provides a clear signal to developers that the entire API surface related to this type is being phased out.
• It prevents new code from being written that depends on the deprecated type.
• It makes it easier to track usage and eventually remove all related code.

Also, I understand that toB256 should be deprecated, as it won't be required anymore when we drop the use of bech32. However, every @deprecated tag is recommending this method, which is also being deprecated. Isn't that misleading?

That's a valid point, I've updated the language 43ae005

[maschad]

@Torres-ssf I suppose since the method name nor signatures will change (although the internal logic will) , you're correct we shouldn't deprecate them 👍🏾

[arboleya]

Warning

Please do not merge this PR until further notice.

This is a hot topic, and there's been some last-minute pondering about this deprecation.

I'll reply to or close this comment with news once there is a consensus about it.

[petertonysmith94]

Converting this to a draft until we have an consensus around this.

[github-actions]

Coverage Report:

Lines	Branches	Functions	Statements
76.67%(+0%)	71.48%(+0%)	75.65%(+0%)	76.76%(+0%)

Changed Files:

Coverage values did not change👌.

The base branch was changed.