executeSubCommand() shouldn't be called if I provide action

[borekb]

Disclaimer: I'm new to Commander, maybe I'm missing something.

I'm trying this very simple example:

program
    .version('1.0.0')
    .command('example', 'example command')
    .action(() => {
        console.log('it is working!');
    })
    .parse(process.argv);

I'd assume that my action() callback is what represents the command, however, it seems that Commander is also trying to execute the module called index-example:

$ node index.js example
it is working!
module.js:473
      throw err;
      ^

Error: Cannot find module 'C:\Temp\commander-test\index-example'
    at Function.Module._resolveFilename (module.js:527:15)
    at Function.Module._load (module.js:453:25)
    at Function.Module.runMain (module.js:665:10)
    at startup (bootstrap_node.js:201:16)
    at bootstrap_node.js:626:3

I thought this is a bug but after inspecting the source code, maybe this is intentional?

I can create index-example.js as a workaround but it's not ideal:

1. I had to create an unnecessary file.
2. Unnecessary spawning a child process.
3. It introduces subtleties like I have to run the script with ".js" explicitly (node index.js example) as calling just node index example will throw error ENOENT: no such file or directory, lstat '...\index'.
4. It causes problems for ts-node (Node + TypeScript) as the source code of Commander assumes .js file extensions. I'm getting Cannot find module 'index.ts-example' error and the workaround is a file named vpmake.ts-example.js; that looks quite weird.

[maxpert]

Having same issue here. Did workaround by doing this:

commander.executeSubCommand = () => false;
commander.parse(process.argv);

Either this behavior should be documented or removed.

[pandapaul]

This happens for me when I provide a description as part of the command call. Despite the presence of the action handler, commander tries to find a file to execute.

const program = require('commander')
const action = require('./some-action-handler')

program
  .command('blah', 'do some stuff')
  .action(action)

But things act as expected when I instead separate the description into a use of .description()

const program = require('commander')
const action = require('./some-action-handler')

program
  .command('blah')
  .description('do some stuff')
  .action(action)

That's pretty goofy. The docs seem to suggest that the presence of the action handler is the key to disabling this behavior, but this behavior seems to say otherwise. After a brief glimpse into the source, I'd point a finger at this: https://github.com/pandapaul/commander.js/blob/master/index.js#L178-L183

Just noticed this other issue pointing to the same problem: #715

And this, which is sort of the other side of the same coin: #633

[hlfshell]

I can confirm this happening on 2.14.1 as well in Windows. @maxpert 's fix does act as a work around if you don't need subcommand at all.

Strangely, it fails finding the file even when it exists as well.

[shadowspawn]

Adding a description to the .command() call currently invokes git-style subcommand mode, which could do with a warning or change in default behaviour when .action() supplied, and better documentation.

[shadowspawn]

Recategorising this as a bug and adding to v3 milestone to have a go at changing the behaviour in a breaking version.

[shadowspawn]

Had a look into this, and not going to attempt it in v3 after all. An insight though: the git-style executable (with description) returns the program for chaining; the action-style subcommand (without description) returns the new command for chaining.

[shadowspawn]

This issue will be resolved when v3.0.0 is released. Available now as a prerelease. See #1001

Reworked the README and JSDoc and TypeScript to hopefully make the two modes of operation clearer. Have not changed the runtime, but will close this issue and see how the changes help.

[shadowspawn]

Reworked the README and JSDoc and TypeScript to hopefully make the two modes of operation clearer. Have not changed the runtime, but will close this issue and see how the changes help.

Shipped in v3: https://github.com/tj/commander.js/releases/tag/v3.0.0