CLI?

[RichardLitt]

What

A CLI for node-ipfs-api

Why

I want to write better docs for this, although that may be being worked on in #58. I was looking through the code line by line, and I think that it would be useful to have the methods docs I am writing in not only README, but in some sort of CLI, like we have with ipfs/go-ipfs.

How

It wouldn't be too hard to get a CLI going for this, and that might be useful for running tests and checking docs before using this in the browser.

Open questions

• Would this result in confusion, given that go-ipfs already has a CLI?
• Would this result in code duplication?
• Is there a better way to display and test methods than in a CLI and a README.md combo?

[daviddias]

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

@whyrusleeping thoughts?

[bcomnes]

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?

[daviddias]

• 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

[jbenet]

@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.

[RichardLitt]

@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

[RichardLitt]

@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!

[victorb]

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.

[RichardLitt]

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.