There are several issues with the current fiojs library. These are not necessarily “showstoppers” for integrators, but they can increase integration complexity:
Mycelium has expressed concern regarding the number of 3rd party libraries included with our Kotlin SDK.
Some wallets have asked for a better understanding of the encryption libraries included in fiojs and how they relate to eosjs.
When creating tools that interact with FIO, the encryption libraries present a problem because they are somewhat non-standard.
It is difficult to integrate with other EOSIO tools because of our use of encryption and some other non-standard interactions.
Several options were discussed with Jimmy regarding the different options for minimizing the pain of keeping up with eosjs and eosjs-ecc changes. We also reviewed other forks of eosjs. The following are the options:
Keep as is. Maintain a separate copy of eosjs and manually merge in commits we think are important.
Pro: no changes to current process
Con: hard to know what changes are important and you can get into a bit of merge hell when you cherry pick.
Create a complete separate fiojs that wraps eosjs and eosjs-ecc
Pro: This would be clean, would clearly separate out fio code, and would allow devs to use eosjs completely separately from FIO.
Con: This will require a lot of rework of our code and is not simple.
Create a fork of eosjs and eosjs-ecc and merge in our fio code
Pro: This makes comparison of upstream changes easier to compare and pull in.
Con: It is not a “clean” separation of FIO code.
Move from a separate copy of eosjs to a fork of eosjs to make it easier to merge upstream changes from eosjs. We would then review commits and do regular merges from eosjs when we do fiojs release.
3/16/21 update from Eric: We may want to consider more drastic updates to fiojs to get it more in line with eosjs or other eos libraries. Need to scope.