Vorpal, a framework for building CLIs(vorpal.js.org)
vorpal.js.org
Vorpal, a framework for building CLIs
http://vorpal.js.org/#
42 comments
My problem is with npm and nodejs dependency, for writing CLI, which essentially means you have to install nodejs and is probably only really useful for nodejs developers.
I can understand that. Fortunately, Node is becoming huge in terms of CLI - there's a ton of really useful CLI apps for all kinds of things. To the point where it becomes advantageous to have NPM installed, Node developer or not. At that point, installation of a CLI app is easier and more uniform than many other methods. My 0.02.
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.
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.
As a Python developer I have not found a single library out there (I tried almost every single popular one out there) helps me write better CLI so I always fall back to argparse.
Since every up-to-date Linux system is shipped with Python, and argparse is part of the stdlib, I don't need to worry about argparse not being available. NodeJs adoption is going up, but if someone is building a CLI for a Rust project using Vorpal, then I have to install another piece of software and bloat my local system. Imagine this goes into my docker container it means the overall size of my container will increase. Of course I typically also install a bunch of packages along with my Python project anyway, like requests library, but because these libraries are typically needed for my backend anyway, the CLI's dependency on requests library is debt free. But in the case of me writing a Rust / Go / Python project but shipping a NodeJS CLI version, that's pretty insane. But don't take this the wrong way, I will write NodeJs and I will look at your library. You have great work, but I want to offer you my opinion on why few people outside of NodeJs will use this to build CLI for their X-language project.
Since every up-to-date Linux system is shipped with Python, and argparse is part of the stdlib, I don't need to worry about argparse not being available. NodeJs adoption is going up, but if someone is building a CLI for a Rust project using Vorpal, then I have to install another piece of software and bloat my local system. Imagine this goes into my docker container it means the overall size of my container will increase. Of course I typically also install a bunch of packages along with my Python project anyway, like requests library, but because these libraries are typically needed for my backend anyway, the CLI's dependency on requests library is debt free. But in the case of me writing a Rust / Go / Python project but shipping a NodeJS CLI version, that's pretty insane. But don't take this the wrong way, I will write NodeJs and I will look at your library. You have great work, but I want to offer you my opinion on why few people outside of NodeJs will use this to build CLI for their X-language project.
I see that point of view - that makes sense.
But a benefit might be cross-platform compatibility seeing as some OSes don't come with, say, grep out of the box. While you could use the native tools, there could be some benefit to writing your own to do exactly what you want consistently.
I don't really disagree with you, but just pointing out there is some benefit to writing one's own CLI.
I don't really disagree with you, but just pointing out there is some benefit to writing one's own CLI.
I think its easier to install cygwin than replace all the command line tools I am used to with Javascript equivalents.
Or install ports of enough to get work done. Ag works very well on Windows.
I am still holding my breath for Windows 10 to start including more and more Unix tools. We finally have ssh to be included with Windows 10 and having tools awk, sed, grep on Windows seems like a logical move for Microsoft EVENTUALLY.
For now I use vagrant all the time when I am on Windows.
For now I use vagrant all the time when I am on Windows.
Sure if you want a full set of native tools I won't suggest otherwise. But a full cygwin install is way more invasive than node, and if you just want some specific tools, vorpal might be for you. Or maybe cygwin is. Whatever works for you.
I think GOW (GNU on Windows) is a better alternative to cygwin.
[deleted]
> But a benefit might be cross-platform compatibility seeing as some OSes don't come with, say, grep out of the box
If you have git installed on your machine you have grep ( windows users) and most of linux command tools.
If you have git installed on your machine you have grep ( windows users) and most of linux command tools.
This looks more like a complete shell replacement than a general-purpose CLI builder.
I agree, I was expecting something like ncurses or something
Something about imitating the semantics of a UNIX shell in JavaScript doesn't sit well with me.
I guess if you're building a CLI intensive application in node to begin with then this library seems like a pretty nifty way to do it. I've used plenty of CLI tools that don't offer auto-complete where it really would be handy to see.
I suppose so. My big concern is that this will lead of a lot of faux-shells with relatively few syntactic similarities.
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.
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.
If I was making an interactive command line, I think I'd want to do it all in shell. Let's say it's a CLI that interacts with a remote server, then I might have a "script" that "starts" a custom CLI by doing:
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.
#!/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.
True. Though in Node, you can make calls to standard programs, so it can act pretty seamlessly. And there's already a lot of direction towards supporting a lot of familiar methods and more. Like this: https://www.npmjs.com/package/cash
* Cash isn't released yet - that's why there's no GH repo. That's my next pjt :)
npm install cash-ls -g doesn't work....would love to use this
cash looks great, but how does chmod work on Windows?
Pretty neat. Just need to remember to restore the environment variables afterwards, especially $PATH.
They're only exported to the sub shell (bash on last line of cli script). Quitting the sub shell would restore them. Perhaps you were confused by the absence of `service:$` in the prompt for the upload command, which I believe was an oversight.
Author of Vorpal here. You can ask me Qs if you'd like.
Coming from other languages it's very confusing what this library does exactly. The screenshots make it look like a full shell, but looking closer it seems to be more of a high-level API that combines readline and optparse functionality. It might be helpful to split up these parts and explain how they improve on using the builtin NodeJS readline module and something like optparse-js.
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?
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?
I get you. Yes, it does combined readline and optparse-type functionality. It's similar to Commander.js, with the exception that you have the option of staying in the "shell" after the first command executes, and then it is its own environment with its own commands.
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.
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.
I see option autocompletion is provided as a service by the framework. What about tab-completion of paths?
Got you covered. Extensions, extensions. Guess I should have advertised that in the site.
https://github.com/vorpaljs/vorpal-autocomplete-fs
https://github.com/vorpaljs/vorpal-autocomplete-fs
I've had a pretty bad time trying to get code coverage with my cli tests. I've ended up using spawn() in my test cases due to most libraries using process.exit() / process.stdout.write() and console.log() (instead of picking one and sticking with it).
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!
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!
Thanks man!
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.
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.
For those who want to make simpler Node CLIs, check out meow[1].
[1] https://github.com/sindresorhus/meow
[1] https://github.com/sindresorhus/meow
Yes, Meow is an excellent tool.
Immersive command line applications. I've already booked my seat on the next intergalactic shuttle.
> The command-line is awesome
Actually, a REPL Xerox style is awesome, a pure UNIX style CLI not much.
Actually, a REPL Xerox style is awesome, a pure UNIX style CLI not much.
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.