Introducing bash-parser dependency #246
Conversation
Conflicts: dist/command.js dist/option.js lib/command.js
Rename variable from Vantage to Vorpal
Updated dev deps and switched to Yarn
Updated Inquirer to v3 and other prod deps
Support default values for options
Remove dist folder
…ig for Babel and ESLint.
Update babel/eslint build config
Convert commands to ES2015
Update lib/history.js to ES2015
Converted UI to ES2015
| match: match, | ||
| matchArgs: matchArgs, | ||
| pipes: pipes | ||
| }); |
There was a problem hiding this comment.
If I had understood correctly (please confirm) command prop contains the raw command string, match contains the eventually found Command object; matchArgs is an array of matched arguments, and pipes is an array of subsequent command in a pipe.
There was a problem hiding this comment.
I think we can introduce the parser here. bash-parser could substitute part of the actual function code to provide same results.
There was a problem hiding this comment.
Yes, you have it right. The entire command execution code including pipe implementation should probably be re-written if we are going to use bash-parser. It needs a re-think from the ground up.
| }); | ||
| vorpal | ||
| .command('overwrite me') | ||
| .command('overwrite_me') |
There was a problem hiding this comment.
Introducing bash-parser, this test fail, because when you .exec 'overwrite me', only overwrite is parsed as command name. me is parsed as argument.
Changing the command name to overwrite_me make the test pass.
There was a problem hiding this comment.
But I notice there are many test failing because the same assumption, that 'overwrite me' (e.g.) could be a single command name. So I fear I'm misunderstanding some vorpal assumption here.
@dthree could you help me?
5 participants
This is an investigatory PR to study the introduction of a POSIX compliant shell code parser using bash-parser.
There is a tween PR on
cashrepo