3 ms·

Author of Vorpal here. You can ask me Qs if you'd like.

by dc2 11y ago

SiVal 11y ago
I see option autocompletion is provided as a service by the framework. What about tab-completion of paths?
- dc2 11y ago
  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
BinaryBullet 11y ago
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!
- dc2 11y ago
  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.
toupeira 11y ago
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?
- dc2 11y ago
  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.

Author of Vorpal here. You can ask me Qs if you'd like.

by dc2 11y ago

Author of Vorpal here. You can ask me Qs if you'd like.

SiVal 11y ago

I see option autocompletion is provided as a service by the framework. What about tab-completion of paths?

dc2 11y ago
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

BinaryBullet 11y ago

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!

dc2 11y ago
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.

toupeira 11y ago

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?

dc2 11y ago
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.