"name" option is broken as of 2.4.0

[lakenen]

One of my command line flags is called '--name', but as of bfa7a73, if the name option is left off, cmd.name is a function. I suppose this is indicative of a larger problem, i.e., options are stored on top-level namespace of the command object.

e.g., say you have this file, mycmd.js

var prog = require('commander');
var command = prog
    .command('mycmd')
    .option('-n, --name [name]', 'specify a name (duh)')
    .action(function(cmd){
      console.log(cmd.name);
    });

prog.parse(process.argv);

you will see the following output:

$ node mycmd.js mycmd
[Function]

$ node mycmd.js mycmd --name Cameron
Cameron

Thoughts?

Is this wrong, or am I missing something?

[thethomaseffect]

Nope, you're not wrong, it's a problem and it will be fixed. Closed as dupe of #283

[lakenen]

Oh whoops, didn't see that!

On Monday, October 27, 2014, Thomas Geraghty notifications@github.com
wrote:

Closed #284 #284.

—
Reply to this email directly or view it on GitHub
#284 (comment).

[zhiyelee]

@thethomaseffect Because name is so common, maybe we should change the Command.prototype.name() to a rarely used name, such as cmdName before this bug is fixed in some future version.

How do u guys think about this? @tonylukasavage @thethomaseffect @SomeKittens

[thethomaseffect]

@zhiyelee Your fix seems like the best option, though changing the public API without a major version increment is unfortunate

[tonylukasavage]

@zhiyelee I wouldn't change the API. It is what people have come to expect and works well in most cases. I already handle this situation, post parse(), in my code in a fashion similar to this:

Object.keys(program.opts()).forEach(function(opt) {
  if (Object.prototype.toString.call(program[opt]) === '[object Function]') {
    delete program[opt];
  } 
});

This removes any option that is an function, hence making undefined any option that wasn't assigned. Works well for me. Perhaps similar logic can be pulled into commander.js directly, making my workaround unneeded, and resolve this issue without an API change.

[lakenen]

What about adding an API method that allows you to get the value of an argument by name?

e.g., something like:

cmd.get('name');

Where get could be something more specific or whatever. That way you don't need a major version bump (it's just a new feature ;).

[lakenen]

Though, TBH, I think this bug should still be fixed properly in the future, whether that means a major version or not.

[thethomaseffect]

I think the best way to solve this is to advise people to use program.opts.option instead of program.option and depreciate the latter option with console messages. When adding options to the program object, it will only add if nothing is at that location already and if there is it'll post a warning.

The advantages of this approach are:

• Using opts instead of the main commander object was the plan for version 3.0.0 anyways since the current api cause too many issues when options have the same same as builtins like filter. That means people's code will be compatible with 3.0.0 when it is released.
• Instead of the error now, it'll be obvious where the code needs to be changed. In this case, only the name option would need to be accessed a different way.

So no breaking the public API and we get to address other bugs too before our next major version. Thoughts?

[lakenen]

Sounds reasonable to me! :)

I actually didn't know I could use prog.opts[name], so clearly calling that out in the docs would be very helpful as well.

[thethomaseffect]

It was only added in a recent release and it's undocumented right now mostly due to not getting the amount of testing it deserves from the collaborators. :)

[roman-vanesyan]

Similar to #105, closed, keep your eyes on the issue.