Skip to content
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

Should .parse() default to using process.argv? #1103

Closed
shadowspawn opened this issue Nov 23, 2019 · 3 comments
Closed

Should .parse() default to using process.argv? #1103

shadowspawn opened this issue Nov 23, 2019 · 3 comments
Milestone

Comments

@shadowspawn
Copy link
Collaborator

I write a lot of test programs where I pass process.argv and that is probably the most common calling signature. i.e.

program.parse(process.argv);

As a convenience, should we default to parsing process.argv if parse is called with no parameters? e.g.

program.parse(); // same as calling program.parse(process.argv)

The downside is it is a bit magical, but it is up to the user whether they want to take the shortcut. I suggest the examples still pass process.argv for clarity.

(I came across this approach in yargs and though it was interesting.)

@shadowspawn
Copy link
Collaborator Author

shadowspawn commented Jan 24, 2020

The new implicit behaviour could also include support for the Electron variation in argv (#512). This would fit into the automatically-do-something-useful intent.

@shadowspawn shadowspawn added the pending release Merged into a branch for a future release, but not released yet label Feb 9, 2020
@shadowspawn shadowspawn added this to the v5.0.0 milestone Feb 9, 2020
@shadowspawn
Copy link
Collaborator Author

Omitting the arguments to .parse()and defaulting to process.argv is included in the published pre-release of Commander v5.0.0 (#1163)

@shadowspawn
Copy link
Collaborator Author

Commander v5.0.0 has been released.

https://github.com/tj/commander.js/releases/tag/v5.0.0

@shadowspawn shadowspawn removed the pending release Merged into a branch for a future release, but not released yet label Mar 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant