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

"name" option is broken as of 2.4.0 #284

Closed
lakenen opened this issue Oct 27, 2014 · 11 comments
Closed

"name" option is broken as of 2.4.0 #284

lakenen opened this issue Oct 27, 2014 · 11 comments

Comments

@lakenen
Copy link

lakenen commented Oct 27, 2014

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
Copy link
Collaborator

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

@lakenen
Copy link
Author

lakenen commented Oct 28, 2014

Oh whoops, didn't see that!

On Monday, October 27, 2014, Thomas Geraghty [email protected]
wrote:

Closed #284 #284.


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

@zhiyelee
Copy link
Collaborator

@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

@zhiyelee zhiyelee reopened this Oct 28, 2014
@thethomaseffect
Copy link
Collaborator

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

@tonylukasavage
Copy link
Contributor

@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
Copy link
Author

lakenen commented Oct 28, 2014

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
Copy link
Author

lakenen commented Oct 28, 2014

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

@thethomaseffect
Copy link
Collaborator

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
Copy link
Author

lakenen commented Oct 28, 2014

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
Copy link
Collaborator

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
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants