hold on this. New added get has will overwrite custom command with same name. #404

So commands will have to be moved out of the objects main scope as well, for this to be viable?

UPDATE: I'm not seeing any conflict with custom commands. Can you provide an example of this case?

I've tested this with the following scenario:

cmd: mycmd
subcmd: mycmd-get

mycmd get -y

works as expected. Am I missing something?

oh, sorry, it's about options.

Just want to give some feedback here to help others avoid a little pitfall: you cannot use --once as an argument, probably because the name collides with some internals of commander. Interestingly, the once argument will revert the expected behavior: myprog --once will set commander.once=undefined, so a falsy value, while running myprog will set it to a function as expected.

I don't want to introduce more these cases until we fix this issue.

I think my pull request fixes that issue.

Options no longer get stored to the object directly.

Before you would have had:

program.once

Now you get:

program._data.once

The following is tested and working:

#!/usr/bin/env node
var program = require('commander');

program
  .version('0.0.1')
  .description('Test')
  .usage('[options] <file>|string')
  .option('-y, --yes', 'Something')
  .option('-o, --once', 'Once')
  .parse(process.argv);


program.has_all(['yes', 'once'], function(yes, once){
    console.log(yes, once);
});

I am still investigating options. For now, I'll note that get() and has() are similar in name and purpose to the new Mapobject, and should probably behave in similar way.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map

I am closing this in favour of #951, which builds on work in this Pull Request and aims for backwards compatibility.

Thank you for your contributions.

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

See #1102