Are you using a fork of ganache-cli(@frangio's ganache-cli-coverage) primarily because you have to pre-fill some specific ethereum accounts with a lot of ether (>1m) in scripts/test.sh? Or are there more reasons?
In testCommand and compileCommand in .solcover.js, you're setting --max-old-space-size=4096. Why?
Are there any plans to migrate to a different set up? Is it safe to "fork" your integration now?
No, the ability to define the accounts and their balances is already present in upstream ganache-cli.
The way that solidity-coverage was implemented required changes in ethereumjs-vm, and that implied changes in ganache-cli, which uses the former. This ended up propagating as changes in all of these packages, which gave the name to the sc-forks GitHub org. The project was abandoned for a while and that’s why we had to create our own fork to update it with support for some of the new opcodes (from Byzantium I think).
I believe the original developer of solidity-coverage is working on a new version that will not require all of these forks, and we will probably migrate to that as soon as it’s usable. The current setup is a pain to maintain. It’s safe to use it, in fact it probably has the most features among the alternatives, but it can be a painful experience if something doesn’t work.
Yup! I ended up exchanging loads of messages in the meantime and it seems version 0.7.0 will be much more stable and easy to use.
Unfortunately, it hasn't been for me. I defaulted to using the latest version of solidity-coverage (0.6.5) and ethereumjs-testrpc-sc (6.5.1-sc.0). That worked, but to be fair it still feels hack-ish.
Bottom line, this looks like something that the Ethereum community as a whole should spend more time (and money) on.