feat: bring your own API client

[alanshaw]

BREAKING CHANGE: library consumers must now npm install ipfs-api manually

This PR resolves #254 and allows people to also use their own API client. It addresses the problem of the ipfs-api dependency in ipfsd-ctl not being up to date with the latest js-ipfs or go-ipfs and would also allow people to use an older IPFS with a compatible API client.

Most importantly, it also means we won't have to spend PR's like this to get the tests to pass on js-ipfs.

[dryajov]

@alanshaw while I like this PR and we've gone back and forth on doing it like this a few times, it's worth pointing out that, this is already possible if using the .apiAddr property on the ipfsd object ipfs = IPFSApi(_ipfsd.apiAddr) - https://github.com/ipfs/js-ipfs-api/blob/master/test/bitswap.spec.js#L25.

[alanshaw]

@dryajov noted. I did see that being done in js-ipfs-api.

Workaround aside, IMHO it's odd to allow people to use their own IPFS node at whatever version but force them to use an API that might not be compatible with it.

It's also worth noting that when using that workaround in the browser, js-ipfsd-ctl will bundle an unused js-ipfs-api (around 280KB gzipped).

If this PR isn't merged then the workaround needs to be documented here instead and I will send a PR to js-ipfs to use it.

[vasco-santos]

I like this solution, and I agree with @alanshaw. We should not allow the usage of an API that might not be compatible with the node.
Nevertheless, I would like to have @diasdavid input on this.

[dryajov]

Workaround aside, IMHO it's odd to allow people to use their own IPFS node at whatever version but force them to use an API that might not be compatible with it.

@alanshaw I tried arguing that point in - #195 (comment) 😀, and something like this was going to be my ultimate solution, I just never really needed it. But that said, I'm 💯 in favor of it.

[daviddias]

Remember that the purpose of this module is not to be a test utility, but actually a module that makes it really nice to spawn and control daemons from JS. I see two things being proposed here:

• Selecting the ipfs-api and daemon implementation you want to use.
• Simplify it for users.

The current setup is already cumbersome. Users have to install manually a go-ipfs/js-ipfs node to make this module work. The only reason why js-ipfs and go-ipfs are not bundled here is because js-ipfs caused troubled for electron apps to build (e.g IPFS Desktop).

It seems that won't be a issue anymore however -- ipfs/js-ipfs#1351 (review) --. So we should reconsider bundling it all again.

That said, yes, a user should be able to inject their own API client.

[daviddias]

Just to be clear. I'm not against of "educating the users to bring their own ipfs and API client", however, that does change the intent of the module and it doesn't solve the issue all together, as if users pick the wrong ipfs-api and ipfs daemon combination, they might get things breaking anyway and the errors might be even from ipfsd-ctl internals.

I advise that we have sane/easy to use defaults and then advanced options for power users (e.g us with our testing).

[alanshaw]

I advise that we have sane/easy to use defaults and then advanced options for power users (e.g us with our testing).

I'm +1 on that. If it is now possible to bundle go-ipfs-dep and ipfs with ipfsd-ctl then I'd also prefer that we did that and allow users to optionally bring their own IPFS and/or API.