-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restore arguments order to pass to subcommands #734
Conversation
to accepts options before arguments cf maxlath/commander.js@1297ae6 and tj/commander.js#734
to accepts options before arguments cf maxlath/commander.js@1297ae6 and tj/commander.js#734
so that option parsing is done by the subcommand, which may have its own options. Addressed case: `cmd subcmd -o arg1 arg2` where `-o` is defined on the subcommand was passing an args array like `[ arg2, -o, arg1 ]` to the subcommand
I think we need some better details about expected pattern for git-style commands! I need to do some experimentation to better understand before reviewing this PR. (I am surprised things are potentially this broken, which makes me wonder if there are some calling patterns which are ok.) |
This is being considered for v3 (since it seems a nasty bug!), but has not passed any reviews yet, and won't be merged until approved. I am willing to help with code changes if needed. |
There is a bug but it is unfortunately harder and more subtle to fix than this. The top level command can have options which are currently removed before calling the sub command. This may not be common, but it would dramatically change the behaviour to pass the original args through to the sub-command. e.g.
Thank you for your contributions. |
hi! sorry for the slow reaction, I made a test repo to demonstrate the issue: https://github.com/maxlath/commander-subcommand-argument-order-demo |
The parsing got a major shakeup and argument order is now preserved in the published pre-release of Commander v5.0.0 (#1163) |
so that option parsing is done by the subcommand, which may have its own options.
Addressed cases of the kind:
cmd subcmd -o arg1 arg2
where-o
is a boolean option defined on the subcommand, and thus will not be identified byparseOptions
when called from the parent command, and fall in the// looks like an option
block, which will alter the arguments order: the subcommand will receive an args array that looks like[ arg2, -o, arg1 ]
Possibly related to #692 and #289