After calling
program.parse(process.argv);
I get
index-server(1) does not exist, try --help
$ node ../../lib/cmd/index.js server
```JavaScript
// 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
.option("-e, --env
export { root }
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?
I have same issue on Mac! Windows works.
Is there a workaround/fix for this issue? It's affecting my automated build on linux as well, works fine on windows.
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
@fabioricali thanks for sharing, can you help me to understand the necessary changes to patch my application?
Here is the workaround I am using for my project:
package.json:
...
{
"bin" : { "my-script": "./my-script.js" }
}
...
For windows the value ./my-script-
For unix the key "my-script-
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
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
So how to fix this issues?
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:
commander looking for wrong subcommand filename, check arguments to parseI'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:
.bin folder first in $PATH and therefore the symlink will point to node_modules and everything works as expectedpackage.json for the other bin optionsnpm -g instead of yarn globalThanks 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
@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.
@acds
The change from #935 is in v2.20.0.
https://github.com/tj/commander.js/compare/v2.19.0...v2.20.0
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
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
Most helpful comment
I have same issue on Mac! Windows works.