Cannot name options/subcommands after commander public methods or JavaScript built-ins

[dobesv]

I tried to create a parameter with the long name 'password' and it didn't work out well, since that conflicts with the method password(). Same would go for 'action', 'option', and so on. Perhaps the parsed options could come back in a separate object? Or be able to assign an alias to those option names?

Workaround currently is to use a different long name so that it doesn't conflict with those.

[tj]

good point haha. perhaps we should have them as program.<prop> by default but also have program.options.<prop> or similar for cases like these

[dobesv]

To clarify the issue a bit more:

Using an option named 'prompt' or 'password' means that:

1. if the user supplies the option, you can't use that method afterwards because it is replaced with a string value from the user.
2. if you want to check if the option was provided (using 'password' in program or program.password != null), it always returns true

[tj]

yeah i know, there's no compromise really, we have to either place the option values somewhere else, or rename the methods

[itay]

My vote is to place the options in program.options - I think it makes it much clearer.

[thethomaseffect]

Changed title of issue to better cover the scope of this problem. program.opts is now available but this is still causing a number of issues for users. using program.option with be depreciated in favor of program.opts.option in a later release unless someone comes up with a better way to handle this issue.

[roman-vanesyan]

Closed, outdated. Feel free to reopen.