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 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:
Coverage remained the same at 100.0% when pulling 42122cb08a4b8e47a87419369adf892dd09974f5 on CaptEmulation:bitcore-lib-as-peer-dependency into b7a6845a4f4c7940884247113a208fe30fcc0e39 on bitpay:master.
Coverage remained the same at 100.0% when pulling 982c9c43e4c6769917e1f1d443c794f3511e2792 on CaptEmulation:bitcore-lib-as-peer-dependency into b7a6845a4f4c7940884247113a208fe30fcc0e39 on bitpay:master.
Coverage remained the same at 100.0% when pulling be7c3d1f197b7ecc5b304b869e005c5a660bd758 on CaptEmulation:bitcore-lib-as-peer-dependency into b7a6845a4f4c7940884247113a208fe30fcc0e39 on bitpay:master.
Coverage remained the same at 100.0% when pulling 1bb691981dd5c3c0746c75353683f5b2f03a9496 on CaptEmulation:bitcore-lib-as-peer-dependency into b7a6845a4f4c7940884247113a208fe30fcc0e39 on bitpay:master.
One wrinkle to using the bitcore stack is the obvious need to have a singleton
bitcore-lib
. Thebitcoin-lib
package hosts thebitcoind
library and there are good reasons to not wanting to have multiplebitcoind
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
inpeerDependencies
. This way the enclosing package can specify whatever version ofbitcoin-lib
it wants andnpm
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/insightI also updated
bitcore-lib
to 0.14 becausebitcore-wallet-service
has already done so and I figured if it was good enough forbitcoin-wallet-service
it's good enough for everything else :smile: