My app has a config option called 'host'. When you run the program with "-h", the help is printed, which is not unexpected.

However, the following output is

const args = require('args')
  .option('interval', 'How often (in seconds) to ping the device', 30, s => 1000 * s)
  .option('delay', 'How long (in seconds) the device must be gone before reporting no presence', 15 * 60, s => 1000 * s)
  .parse(process.argv)

Note that there are two '-h' options.

People should be able to show the help whenever they want to. Maybe rename to .showHelp()

Some people don't like magic globals. So we should allow this (but still keep magic properties):

const properties = args.parse(process.argv)

Hi,

If there is already a short version with a given letter, I think next options starting with same letter should not expose a short version at all.

Here I'm trying to create a list PR and my --cors options conflits with the --cache option:

    -c, --cache <n>    How long static files should be cached in the browser (seconds)
    -c, --cors <list>  Setup * CORS headers to allow requests from any origin

As far as I understand, I can't setup no short version at all or a short version of more than 1 letter. It means there can't be more than 26 options available and I have to pick a random letter for my cors options

Currently, it looks like this (we need to remove [value]):

-v, --version [value]  Output the version number

Makes promises fail loudly instead of silently (without .catch). Might not make sense for submodules, but for CLIs, it's pretty great.

https://github.com/sindresorhus/loud-rejection

-h is pretty cryptic and doesn't help newbs. Also having two ways for outputting the usage information is just confusing to everyone!

const args = require('args')

args
  .option('logs', 'Prints the build logs', true, Boolean)

console.error(args.parse(process.argv))
// { l: false, logs: false }

Expected false to be true.

due to this
https://github.com/leo/args/blob/master/src/index.js#L312

for case when you have your command in folder like

script/
 - test.js
- test-hello.js

with

//test 
args.command('hello', 'say hello');

it will fail to find command with test.js-hello.

1. I'd expect to handle extension.
2. it also seem to look for test-hello in root folder instead of scripts.

anyone?

I really like this package and was wondering if you were planning on adding the ability to add information to the 'Usage' field?

For example:

Usage: haha [options] [command] <directory>

I think this syntax is more readable and easier to understand:

args
  .option('a', 'abc')
  .command('b', 'def')
  .config({name: 'abcdef'})

args.parse(process.argv)

What do you think?

Flags are options without a value... Might be a great idea to make this more explicit.

since this one does not allow to pass 2nd argument opts to minimist
https://github.com/leo/args/blob/master/src/index.js#L387

there is no way to make parser treat number looking values as strings like here https://github.com/substack/minimist#var-argv--parseargsargs-opts.

Would a pull request be accepted that allows an argument to be false by default? Is there any way of doing this already?

This would be useful for implementing a command line switch to enable a specific function that is disabled by default.

This is maybe just helpful while developing, but when i registered a subcommand with .command()and forgot to npm link and/or add the binary to the package.json we could output a more user friendly error message to prevent issues like these: #69 #46

My application accepts no commands, but has options. The setup looks like this

const args = require('args')
  .option('interval', 'How often (in seconds) to ping the device', 30, s => 1000 * s)
  .option('delay', 'How long (in seconds) the device must be gone before reporting no presence', 15 * 60, s => 1000 * s)
  .parse(process.argv)

However, when I run the app with --help, the output looks like this

[chris:~/device-presence] master(+6/-1) ± node index.js --help

  Usage: index.js [options] [command]

  Commands:

    help  Display help

  Options:

    -d, --delay <n>     How long (in seconds) the device must be gone before reporting no presence
    -h, --help          Output usage information
    -i, --interval <n>  How often (in seconds) to ping the device
    -v, --version       Output the version number

Since my application does not use commands, it would be nice if the usage section did not imply that it did.

This is a weird one. When passing a value to an argument via the command line, while also defining a fallback on process.env, [object Object] is returned instead of the correct value.

I took these steps to reproduce the issue:

1. In a new directory do npm install args
2. Create a file fail.js with these contents:

const args = require('args');
args.option(['p', 'port'], 'The port to run on', process.env.PORT || 3000);
const config = args.parse(process.argv);
console.log(`Your port is: ${config.port}`);

1. Run the following tests on the CLI and observe the weird results:

$ node fail.js
Your port is: 3000 # all good

$ node fail.js -p 1000
Your port is: 1000 # all good

$ PORT=1000 node fail.js
Your port is: 1000 # all good

$ PORT=1000 node fail.js -p 1001
Your port is: [object Object] # failure

Note if I take out process.env in that script and instead specify a single default value of 3000 with no fallback everything works as expected.

Happy to look into resolving the issue if you don't have time to, as it's currently causing bugs in the master branch of slackin here: rauchg/slackin#206

The script program defines its option like this:

args.option('parameters', "Your parameters", []);
const flags = args.parse(process.argv);
console.log(flags);

A test in a terminal returns an empty array:

program command --parameters 10 20

The subcommand binary isn't found on windows environments

C:\> tool config get option
C:\Users\jduque\AppData\Roaming\npm\node_modules\tool\node_modules\args\index.js:342
throw err
^

Error: spawn tool.js-config ENOENT

Just like now running now deploy by default, we could add the ability to specify a default subcommand.
Maybe like this:
.defaultCommand('deploy', 'Deploy') or
.command('deploy', 'Deploy', { defaultCommand: true }
or via the options in .parse(process.argv, { defaultCommand: 'deploy' }

If I run npm install release -g && release -v, I get 3.0.1 - which is the latest version of args.

🤔 🤷‍♂️

The word "Usage" is output in black, making it unreadable. The dark blue isn't the greatest either…

Hi!

So I have this simple script

var args = require('args');
var path = require('path');

var availableTypes = [
  'all',
  'products',
  'conversion-chart'
];

args.option('type', 'The type of index to update ('+ availableTypes.join(', ') +')');
/*
args.options([
  { name: 'type', description: 'The type of index to update ('+ availableTypes.join(', ') +')' }
]);
*/

args.examples([
  { usage: path.basename(__filename) + ' update --type all', description: 'Update all search indexes.' },
  { usage: path.basename(__filename) + ' update --type products --type conversion-chart', description: 'Update only 2 specific search indexes.' }
]);

var flags = args.parse(process.argv, {
  name: path.basename(__filename),
  version: false
});

console.log(flags);

When I call the script scripts.js -t all

I get this

{ t: 'all', type: 'all' }

Now if I comment the args.option and uncomment args.options and run it again, I get this :

{ t: false, type: false }

shouldn't that give the same results or am I missing something?

Hi 👋 Thanks for a great args parser.

What do you think of the possibility to send in an option that will stop the process.exit() from the help generation? It can be useful in systems that has plugins which themselves has options. The snippet below shows an example use case:

const {adapter} = args
  .option(['a', 'adapter'], 'The adapter used')
  .parse(argv, { help: false, exit: false })

const options = args
  .option(['a', 'adapter'], 'The adapter used')
  .options(adapter.options)
  .parse(argv, { name: `some-cli (with adapter "${adapter}")`)

I am happy to implement it if you think it would be an valuable to the library.

• Another advantage over commander.
• Helps with doing a cleanup before showing the help.
• Might also need to make .showHelp() work

Devs should be able to specify these using .examples() or something like that.

Run now -h to see what I'm talking about!

For example .colors({mainColor: 'red', subColor: 'bold' }) would output the commands and options in red, and the description in chalk.bold instead of chalk.dim

Since chalk is being used in the main library it needs to be moved to dependencies.

Hey @leo,
This fix might not be necessary, but when I created my first args subcommand I got:

Error: spawn gest-test ENOENT
    at exports._errnoException (util.js:1028:11)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:193:32)
    at onErrorNT (internal/child_process.js:359:16)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    ...

and addingpath.join(__dirname, this.binary + '-' + (Array.isArray(details.usage) ? details.usage[0] : details.usage)) was my quick fix, but this only fixed the problem if I named my binary gest-test, not gest-test.js. A better solution would be to only spawn the file mapped to by package.json's bin, or maybe default to .js.

I can tackle this, but I would like to know which approach you think is best.
-- @mfix22

The showHelp will not console.log bigger helps due to the process.exit(). I think using process.exitCode or no exit at all would be better, and let the users to handle their exit on help.

thanks

Hi! The new behavior of detecting unknown options is broken for subcommands. E.g.

$ foo bar -o=baz
The option "o" is unknown. Here's a list of all available options:
[etc]

In v2.4 (which I upgraded from) it works fine.

Since defaults are used much more often than initializers, this...

.option(name, description, init, default)

...should be this...

.option(name, description, default, init)

@ntwcklng We kinda forgot that people need to be able to specify an unknown sub command, as a path to a directory or similar:

serve directory

micro directory

Both of these would throw the help, because the "sub command" is unknown.

Of course we could just add the ability to deactivate this using a config parameter, but since these are like 90% of the cases, I would rather only use it for options, not sub commands. 😊 🙏

The only way to get to the values of the options shall be .parse(). For example, the current way of doing it makes option names conflict with existing methods of the module.

Since this property comes directly from minimist, we need to remove the paths of the binaries.

i.e.

    -c, --cache [value]       Directory to cache stuffs (defaults to "/tmp/foo")

instead of (currently):

    -c, --cache [value]       Directory to cache stuffs

I can submit a PR if desired.

When outputting the usage information, for example.

I want to specify a string option named "--version" but because of the default version option, it will not let me override it (as far as I can tell). I can submit a patch if this isn't supported.

This will make it easy for devs to find out who created a CLI

#88 (comment)

Suggested by @rauchg: .parse(, { help: false, version: false })

This will make managing the code and adding features in the future much easier!

0.10, 0.12