Description

This draft of migration from BN.js to native BigInt. It needs MetaMask/utils#255 to be merged and released first.

Native BigInt is much much faster than JS only BN implementation. This could improve app performance in many places like account list, login, dashboard etc. I already measured useAccounts hook and it made it 7x faster 220ms => 30ms.

Proposal for handling migration:

I moved cloned previous file index.js to legacy.js and updated imports everywhere to use this old implementation. Then I migrated whole old index.js to TS and to use BigInt. I also marked all legacy functions as deprecated so they could be spotted more easily during future refactoring and replaced with new implementation.

I think this approach is best in current situation because:

1. Even that I tried my best I could have introduced some bugs it's better to introduce new functions slowly
2. We are on tight schedule with performance improvements and updating these functions across whole codebase could take quite a long time and I am not even talking about testing and PR review
3. I also added TS types which is causing type errors in some places where new functions are used because previous versions were typed as any.

TODOs:

• merge Feat/migrate units conversion utils utils#255
• merge chore: improve Engine tests stability #18949 and then rebase
• in Engine.ts, around line ~1916 there is function toHexadecimal and while migrating it to new implementation with bigint I noticed that i receives params like solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp . In old implementation it causes toHexadecimal return NaN and in my new implementation it throws error. I guess this might be causing bug even in current implementation like total balance not being correct if there is more than one Solana account or something like that.
• How to gracefully migrate from old BN? I would suggest keeping old BN implementation and only that functions deprecated.

Changelog

CHANGELOG entry:

Related issues

Fixes:

Manual testing steps

1. Check that total balance across the app is correct for different SRPs (combinations of coins/tokens/networks etc.)

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I’ve followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.