#!/usr/bin/env bash
export REMOTE_ADDR="$1"
export PATH="$(dirname $0)/commands:$PATH"
export PS1='service:\$ '
bash
$ server-cli https://myservice.com
service:$ which upload
/path/to/server-cli/commands/upload
$ upload ./my-file.png
uploading.......
Along with this, you get a pretty workable programming language (shell), access to the local environment, access to the "standard library" of commands you know, and so on.
Also, a question about piping: in your example the "say" command is hard-coded to use the argument called "words", and the "reverse" command is hard-coded to read from standard input. This seems very limited compared to piping in a real shell, shouldn't each command receive a string/array of input and return output so they can be piped to each other without having to know about it?
On piping, I hard coded those to keep it short. Every single command can receive "args.stdin", which is a stdin stream from previous commands. To pipe out, the "this.log" command does all of the heavy lifting.
So all you would need to do is expect both "args.stdin" and "args.words" - that would cover input both from a directly executed command as well as stdin. This works very well in practice.
How are globals used in the vorpal codebase? Is it going to be easier to write my tests (and actually get code coverage with istanbul working)?
I like the site, and the API overview. The library looks nice!
Yeah, it's got stdout piping methods, etc. which make it easy. It's also got UI manipulation methods so you can simulate user action. I haven't particularly had any trouble writing tests, but really it depends on your use case, which I'm not familiar with.
Start from scratch just because you don't want to read the manual of the right technology, convince lots of people to adopt with a cool site, spend the next 5 years updating your project to get to 10% of the 20yr old projects you ignored.
disclaimer: mostly javascript developer nowadays. but salty.
My purpose in writing Vorpal is to make building CLIs accessible to a wider audience. While haters will hate JS, it nevertheless has a very broad use and accessibility.
I don't really disagree with you, but just pointing out there is some benefit to writing one's own CLI.
If you have git installed on your machine you have grep ( windows users) and most of linux command tools.
It's a personal preference, but I'd much prefer my programs (node or otherwise) treat the shell like the first class citizen it is and use it to its fullest extent.
Actually, a REPL Xerox style is awesome, a pure UNIX style CLI not much.