bitpay
Use bitcore-lib as a peerDependency
One wrinkle to using the bitcore stack is the obvious need to have a singleton bitcore-lib. The bitcoin-lib package hosts the bitcoind library and there are good reasons to not wanting to have multiple bitcoind instances running on the same machine.
However, I am not a fan of the runtime check and would rather have all packages be declaring bitcoin-lib in peerDependencies. This way the enclosing package can specify whatever version of bitcoin-lib it wants and npm will inform user if there is an unmet dependency at install time rather than run time.
I have a working example of bitcore-lib running as a peerDependency at bitcore-docker-build which is also running testnet at bitcore.soapbubble.online/insight
I also updated bitcore-lib to 0.14 because bitcore-wallet-service has already done so and I figured if it was good enough for bitcoin-wallet-service it's good enough for everything else :smile:
Also depends on:
- https://github.com/bitpay/bitcore-node/pull/500
- https://github.com/bitpay/bitcore-p2p/pull/92
- https://github.com/bitpay/insight-api/pull/501
- https://github.com/bitpay/bitcore-wallet-service/pull/639
Coverage remained the same at 100.0% when pulling 2c09ad7459a33f5c692de2e4db00e912ca8ab9ea on CaptEmulation:bitcore-lib-as-peer-depdency into 98a54319246bfabd442f94cac42ab5c9486d3b46 on bitpay:master.
well from a Travis CI perspective I certainly see the flaw in my plan
Coverage remained the same at 100.0% when pulling c090e45f6e397ee087984184124f8b37404054af on CaptEmulation:bitcore-lib-as-peer-depdency into 98a54319246bfabd442f94cac42ab5c9486d3b46 on bitpay:master.
Coverage remained the same at 100.0% when pulling c367194bce0167f31cd331af13c96bd197ae6021 on CaptEmulation:bitcore-lib-as-peer-depdency into 98a54319246bfabd442f94cac42ab5c9486d3b46 on bitpay:master.
Coverage remained the same at 100.0% when pulling b2347d07fdf5afaf04441e73ed84daa66fd01291 on CaptEmulation:bitcore-lib-as-peer-depdency into 98a54319246bfabd442f94cac42ab5c9486d3b46 on bitpay:master.