Based on a 11/23/20 discussion with Andrew, Jimmy, Eric:

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.

Based on the discussion we recommend the fork option.

I think the best solution to fork eosjs and create a commit with fiojs changes, so then we could fetch upstream and merge eosjs updates. Also we could do the same with eosjs-ecc, or check if it has changes with ecc folder code, maybe we could just copy-paste all files.

When we get to this we will want to have a call with Jimmy to discuss what was changed in fiojs.

If we want to maintain fiojs going forward, we need to do a regular merge of relevant fixes from eosjs into fiojs.