CLI? about js-ipfs-http-client HOT 8 CLOSED

Would this result in confusion, given that go-ipfs already has a CLI?

@whyrusleeping thoughts?

from js-ipfs-http-client.

Honestly, I'm still confused what this module is for. Can someone clarify?

Generally, when writing a node module, I write a JS API that other programs can require, and then also bundle in a cli that consumes that api to expose the cli ux as a way to help validate the first use of that API.

node-ipfs is a library, but will offer a cli the same way go-ipfs does presumably. node-ipfsd-ctl provides a library for controlling an ipfs daemon provided by go-ipfs through child process.

How is this module different than what node-ipfs or node-ipfsd-ctl offers?

from js-ipfs-http-client.

• node-ipfs is (will be) the full implementation of an IPFS node (just like go-ipfs), but in Node.js
• node-ipfsd-ctl is a module to spawn a go-ipfs process and manage it
• node-ipfs-api is a client library for the HTTP API that an IPFS node exposes

from js-ipfs-http-client.

@RichardLitt what's the need that go-ipfs cli does not satisfy? it's the definition of complete. it may be a waste of time to do it over node-ipfs-api at this time, given that it exists and things are still evolving. functionality would also diverge, giving us two different CLIs and hard work reconciling them.

from js-ipfs-http-client.

@jbenet: For this reason, stated by @bcomnes:

Generally, when writing a node module, I write a JS API that other programs can require, and then also bundle in a cli that consumes that api to expose the cli ux as a way to help validate the first use of that API.

I'd agree with that. If it wouldn't be easy and/or would be too confusing, let's not do it; I just wanted to field this question because I think it would help with testing

from js-ipfs-http-client.

@victorbjelkholm asked for clarification on IRC, so I must not be saying this right. Here's a rough idea of my thinking: when I build a node module these days, I sometimes use https://github.com/sindresorhus/generator-nm, which basically scaffolds out the module without me having to create everything myself. One of the things that is included in this scaffold is a cli.js file. Here's an example of one such file. It is just a shell that allows me to test out various functions exported from a CLI, nothing else, which allows for easier testing of what options are allowed, what the output is, and so on. I think that's useful, and is something that node-ipfs-api might benefit from. I may be completely out of scope in what I think is possible here, and if so, please let me know!

from js-ipfs-http-client.

My concern is regarding using a CLI to test things that should really be automated tested instead. Maybe there is a use case in having a CLI for node-ipfs but I'm sure node-ipfs-api should be without a CLI. It's a client library for JS, interacting with the ipfs daemon API.

Otherwise, maybe it makes sense to have node-ipfs-cli that uses this library. But having it inside here feels bloated.

from js-ipfs-http-client.

Tests... would actually be a lot better for what I'm asking for. You're right. Ok. Well, that solves this for me. The answer is no, it shouldn't have a CLI.

from js-ipfs-http-client.