Use bitcore-lib as a peerDependency

[CaptEmulation]

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:

[CaptEmulation]

Also depends on:

• 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
• https://github.com/bitpay/bitcore-message/pull/27

[CaptEmulation]

re: the travis failures on node v0.10.25 which runs with npm 1.x. Can reproduce locally. They do not occur for me locally on v0.10.48 which runs with npm 2.x. So it appears that peerDependencies only really works with >= npm2. Installing bitcore-lib on the side on npm1 just leads to the duplicate bitcore-lib problem. :disappointed:

[CaptEmulation]

So are node 0.10.x and npm 1 still supported? These versions have been EOL since last year: https://github.com/nodejs/LTS#lts-schedule1

peerDependencies give you the control of enabling better control of runaway copies of installed modules as well as the install time version checks. The existing duplication check code can remain to cover issues of projects pulling in other projects that themselves have a hard dependency on bitcore-lib.