(1) does not exist, try --help

[zoecarver]

After calling

program.parse(process.argv);

I get

index-server(1) does not exist, try --help

Commands Run

$ node ../../lib/cmd/index.js server

Relevant Code

// index.js
const { root } = require('./root');
root.parse(process.argv);

//root.js
import * as root from "commander";
root
  .version(version, "-v, --version")
  .description("description")
  .option("-s, --select <id>", "select")
  .option("-e, --env <env>", "Environment to use for commands.")

export { root }

[shadowspawn]

I was not able to reproduce with your code fragment, but it looks like you have (accidentally) invoked the Git-style sub-commands processing which searches for separate executables.

Do you have code like root.command("server", description) in your failing program?

[fabioricali]

I have same issue on Mac! Windows works.

[knyy]

Is there a workaround/fix for this issue? It's affecting my automated build on linux as well, works fine on windows.

[fabioricali]

It's terrible but works fine 🥇

I'have created a simple file he is looking for
https://github.com/dozjs/doz-cli/blob/master/src/doz-component.js

[knyy]

@fabioricali thanks for sharing, can you help me to understand the necessary changes to patch my application?

[knyy]

Here is the workaround I am using for my project:

package.json:

... 
{
 "bin" : { "my-script": "./my-script.js" }
}
...

For windows the value ./my-script- is used to try and find the executable file.
For unix the key "my-script-" is used to try and find the executable file.

If the key and value in package json bin is the same it works fine on both unix and windows. We wont get the not found error (which occurs if package.json 's package.bin is "my-script" : "./index.js").

my-script.js

  var program = require('commander');
  program
    .command('start', 'Start application dev server.') // sub-command name
    .command('build', 'Build application artifacts.')
    .command('test', 'Run tests in application.')
    .command('generate', 'Generate application w/ scafolding.')
    .parse(process.argv);

Folder structure:

./my-scripts.js
./my-scripts-build.js
./my-scripts-start.js
./my-scripts-generate.js
./my-scripts-test.js

[jameelmoses]

any update on this? ive tried @fabioricali and @knyy's workarounds with no success.

i cannot reproduce the issue locally using yarn link or npm link but after publishing to npm and installing with yarn, the issue appears.

also, if i remove the globally installed yarn package and install with npm instead of yarn it works

[dandananddada]

So how to fix this issues?

[shadowspawn]

Looking at the code and experimenting, commander effectively uses argv[1] to construct the filename for the subcommand. (Actually the second argument to program.parse() ) This can give different results depending on the launch method if your command name, source filename, and package folder name are different.

Suppose you have a subcommand and have not created its source file yet:

program.command('generate', 'Generate application w/ scafolding.');
console.log(`argv[1] is ${process.argv[1]}`);
program.parse(process.argv);

With the package in a directory called fab-dir and package.json containing:

"bin" : { "fab": "./index.js" }

I see these results on macOS, and from description by @knyy there is a platform unix/windows difference for the first case as well.

$ npm link
$ fab generate
argv[1] is /usr/local/bin/fab
error: fab-generate(1) does not exist, try --help

$ node index.js generate
argv[1] is /Users/john/Documents/Sandpits/fab-dir/index.js
error: index-generate(1) does not exist, try --help

$ node . generate
argv[1] is /Users/john/Documents/Sandpits/fab-dir
error: fab-dir-generate(1) does not exist, try --help

So, tips:

• to debug commander looking for wrong subcommand filename, check arguments to parse
• use matching name for "bin" command and its source file (as per @knyy)

[david-mohr]

I'm on Linux and found this issue while searching for subcommand "does not exist" errors. Simliar to @jameelmoses I found that yarn global was causing the issue. Yarn has changed from symlinking /usr/local/bin/exe directly to the node_modules folder to using an intermediate .bin folder which then continues to link onto the node_modules folder.

In short, commander is stuck looking for .bin/exe-sub which doesn't exist, but node_modules/exe/exe-sub does. I have found a few possible workarounds:

• Put this .bin folder first in $PATH and therefore the symlink will point to node_modules and everything works as expected
• Add additional entries to package.json for the other bin options
• Use npm -g instead of yarn global

[shadowspawn]

Thanks for the work-arounds @david-mohr

There is a change being prepared for release in Commander v2.20.0 which should help with the Yarn issue in particular: #935

[acds]

@shadowspawn did it make the 2.20.0 release - I fear not?

currently running 2.20.0 on MacOS it seems that even if one uses the .action syntax, the code still requires the gitstyle js file per command?

As a side question, is is possible to have global options, and commands, such that the global option provide the ability to override the commands behavior.

[shadowspawn]

@acds
The change from #935 is in v2.20.0.
v2.19.0...v2.20.0

[shadowspawn]

There will be a work-around for this issue when v3.0.0 is released, with an executableFile option to provide custom name. Available now as a prerelease. See #1001

[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