Triage: Namespace pollution

[shadowspawn]

The current code uses the same namespace for user specified options, user specified arguments, and command.Command internals. Opened this issue to collect the related issues found during triage.

Issues:

• Cannot name options/subcommands after commander public methods or JavaScript built-ins #19 Cannot name options/subcommands after commander public methods or JavaScript built-ins
• '--domain' option may cause problem #105 '--domain' option may cause problem
• Option values should not be added to the command instance. #183 Option values should not be added to the command instance.
• "name" option is broken as of 2.4.0 #284 "name" option is broken as of 2.4.0
• Bug and Design Flaw: Option "--opts" clashes with Command#opts function #334 Bug and Design Flaw: Option "--opts" clashes with Command#opts function
• Breaks when using "domain" as an option #370 Breaks when using "domain" as an option
• Command name "inspect" causes weird behaviour #377 Command name "inspect" causes weird behaviour
• argument 'once' (and probably others) cause naming collision #404 argument 'once' (and probably others) cause naming collision
• It causes unexpected result if arguments are the same as option name #483 It causes unexpected result if arguments are the same as option name
• Move parsed options into a data object #514 Move parsed options into a data object
• Using .name and .description has unexpected results. #516 Using .name and .description has unexpected results.
• program.opts() can be overridden by an option #584 program.opts() can be overridden by an option
• Error when option --alias is defined #592 Error when option --alias is defined
• Error when argument has same name as a flag #629 Error when argument has same name as a flag
• Options object is not strictly the user input #644 Options object is not strictly the user input
• Init value of option '--name' is a [Function] #648 Init value of option '--name' is a [Function]

Pull Requests:

• Data overload #515 Data overload
• Fix options key name conflict with commander object's' key #673 Fix options key name conflict with commander object's' key

Fixing this will be a major breaking change. To manage the disruption perhaps we can make a new approach opt-in (non-breaking), then make the new behaviour default (breaking), before finally deprecating the old behaviour.

[shadowspawn]

I have opened a Pull Request which allows storing option values separately rather than as command properties (access using .opts()), and allows passing the options (rather than the command) to the action handler.

See #1102

[shadowspawn]

Added .storeOptionsAsProperties() and .passCommandToAction() in Commander 4.1.

See: https://github.com/tj/commander.js#avoiding-option-name-clashes

[shadowspawn]

Adding new issues for reference, encouragement for changing the default behaviour:

• Can not use action as option name #1020 Can not use action as option name
• requiredOption doesn't work for option named 'action' #1160 requiredOption doesn't work for option named 'action'
• Cannot have option named parent #1212 Cannot have option named parent
• TypeError: this.name is not a function #1226 TypeError: this.name is not a function
• Adding --no-emit option results in error #1237 Adding --no-emit option results in error
• Handling of "--version" program option is buggy #1252 Handling of "--version" program option is buggy
• Add support for multiple aliases #1236 Add support for multiple aliases (Add support for multiple aliases #1236 (comment))
• this.name is not a function when a subcommand with option --name is used #1282 this.name is not a function when a subcommand with option --name is used
• cannot use --parent argument #1401 cannot use --parent argument