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

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

@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

@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 👍🏾

Coverage Report: