In addition to showing the default value (#43), it would be useful to print what the valid options are.

It seems child_process.spawn has its own way to provide arguments that's somehow different from the shell. If i provide as arguments ['-t 95'], bossy gets the array as it is, and not ['-t', '95'] as it would expect, so I get a missing value error in return. Happened to me from gulp-lab if it matters.

Could you push a new update?

Remove Makefile
Remove root index.js
Update package.json license field

Currently, if you invoke the command line asking for help (ex: "-h") you MUST satisfy all the required arguments or you will get an error object back instead of a parsed object. While the net result is the same, it seems a little backwards. You should be able to pass in "-h".

We could either attach h to the resultant Error object or add an extra option to the type definition of help to add some special treatment for help type definitions.

The goal is to make testing this easier

if (args instanceof Error) {
  console.error('there was an error');
  return;
}

if (args.h) {
  console.log('you asked for help');
  return;
}

In order to get to the args.h block, you have to supply ALL the required arguments.

Thoughts?

It should be formatted as:

-n, --name

For example:

name: {
   alias: 'n'
}

When parsing this definition, the result should have both .name and .n assigned the same value.

For example, -i42 should be equivalent to -i 42.

This would be more consistent with the unix built-ins.

Hi,
I would like to begin working on hapijs/lab#285 and in order to support this feature, it is necessary for bossy to somehow parse multiple values in for a given option. I am not quite sure what the appropriate pattern for this might be, either a comma separated list:

--reporter lcov,clover,html

Or whether they should be specified multiple times but added to an array

--reporter lcov --reporter clover --reporter html

I would definitely also like to try implementing this feature in bossy myself, so any guidance on enabling this behavior (or if there is another pattern you would like to suggest) I am all ears.

Thank you!

If you do lab -help (note using a single -), the message is not helping in identifying what you did wrong. Some problem for any of the options.

Moved from hapijs/lab#194

I wonder if it would be awesome to have a joi based cli parser?!

node v4 and latest, ES6, etc.

On these lines here we are slicing off the first two arguments which makes sense when working with process.argv, but if you are overriding that with your own arguments array, we shouldn't do that. Currently, users would have to pad their argument array by two.

Bossy.usage() gives an incorrect way of calling alias shortname when greater than 1 character.

Given:

./sample.js

const definition = {
    options: {
        description: 'options',
        alias: 'o'
    },
    organization: {
        description: 'orgs',
        alias: 'org' // this should console log usage as --org not -org
    }
};

const args = Bossy.parse(definition);

console.log(
    Bossy.usage(definition)
);

console.log(args);

The following happens:

node sample

Options:                           

  -o, --options           options
  -org, --organization    orgs

{
  options: undefined,
  o: undefined,
  organization: undefined,
  org: undefined
}

node sample -org test

Options:                           

  -o, --options           options
  -org, --organization    orgs

Error: Invalid option: options missing value
    at Object.internals.formatError (project/node_modules/@hapi/bossy/lib/index.js:344:12)
    at Object.exports.parse (project/node_modules/@hapi/bossy/lib/index.js:73:43)
    at Object.<anonymous> (project/bin/sample:20:20)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:17:47 {
  data: null,
  isBoom: true,
  isServer: true,
  output: {
    statusCode: 500,
    payload: {
      statusCode: 500,
      error: 'Internal Server Error',
      message: 'An internal server error occurred'
    },
    headers: {}
  }
}

But this works:

node sample --org test

Options:                           

  -o, --options           options
  -org, --organization    orgs

{ organization: 'test', options: undefined, o: undefined, org: 'test' }

The documentation says:

The definition object should be structured with each object key representing the short form of an available command line argument.

However sometimes it's not easy to find a letter for the long form when the letter is already in use for an other option. Or sometimes I just don't want to allow short form for verbosity.

At the moment if I don't specify the short form, then usage information is wrong (-something instead of --something):

const definition = {
  help: {
    description: 'Show help',
    alias: 'h',
    type: 'boolean'
  },
  something: {
    description: 'Do something',
    type: 'boolean'
  }
};

Options:                 

  -h, --help    Show help
  -something    Do something

Another good example is lab. The definition in lab doesn't even follow what is in the documentation (use short form for definition object keys):

https://github.com/hapijs/lab/blob/master/lib/cli.js#L129

I think it would make more sense to use the long form as object keys.

I see two open milestones, each with code changes committed to master... What's going on?

default to process.argv unless options.argv is provided

Closed by cc5152a

Able to specify valid values for the given key. Results in an error if the supplied user input isn't found in the valid array of values.

For example:

lab --pattern -test

Here is a failed test case to demonstrate the issue:

    it('is able to parse a string that begins with -', (done) => {

        const line = '-a -test';
        const definition = {
            a: {
                type: 'string'
            }
        };

        const argv = parse(line, definition);
        expect(argv).to.deep.equal({ a: '-test'});

        done();
    });

Original issue: hapijs/lab#483

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet.
We recommend using:

• CircleCI
• Travis CI
• Buildkite
• CodeShip
• Azure Pipelines
• TeamCity
• Buddy
• AppVeyor
  But Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.