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.
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:
All you are doing here is adding all your custom commands (which are just command line applications), and starting up the CLI by giving it some context of some sort. All I have here is $REMOTE_ADDR (which by convention a command like upload would read), but you could have auth or whatever.
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
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.
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!
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.
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?
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.
ah, the javascript developer mindset applied to CLI development.
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 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.
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.
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.
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 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.
42 comments
[ 4.0 ms ] story [ 48.0 ms ] threadIt'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.
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.
https://github.com/vorpaljs/vorpal-autocomplete-fs
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.
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.
[1] https://github.com/sindresorhus/meow
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.
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'm yet to encounter those.
I don't really disagree with you, but just pointing out there is some benefit to writing one's own CLI.
For now I use vagrant all the time when I am on Windows.
If you have git installed on your machine you have grep ( windows users) and most of linux command tools.
Actually, a REPL Xerox style is awesome, a pure UNIX style CLI not much.