Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cli `--help` command showing incorrect commands #640

blacksun1 opened this issue Sep 12, 2016 · 1 comment

cli `--help` command showing incorrect commands #640

blacksun1 opened this issue Sep 12, 2016 · 1 comment


Copy link

@blacksun1 blacksun1 commented Sep 12, 2016


So, I think the code at is wrong... or maybe that bossy just doesn't work the way you want it to (I think it might be the later)

If you look at the output for the help it looks like the following

> ./bin/lab --help  
Usage: lab [options] [path]


  -a, --assert                specify an assertion library module path to require and make available under Lab.assertions
  -C, --colors                enable color output (defaults to terminal capabilities)
  -M, --context-timeout       timeout for before, after, beforeEach, afterEach in milliseconds
  -c, --coverage              enable code coverage analysis
  -coverage-path              set code coverage path
  -coverage-exclude           set code coverage excludes
  -D, --debug                 print the stack during a domain error event
  -d, --dry                   skip all tests (dry run)
  -e, --environment           value to set NODE_ENV before tests
  -f, --flat                  prevent recursive collection of tests within the provided path
  -I, --globals               ignore a list of globals for the leak detection (comma separated)
  -g, --grep                  only run tests matching the given pattern which is internally compiled to a RegExp
  -h, --help                  display usage options
  -i, --id                    test identifier
  -l, --leaks                 disable global variable leaks detection
  -L, --lint                  enable linting
  -n, --linter                linter path to use
  -lint-fix                   apply any fixes from the linter.
  -lint-options               specify options to pass to linting program. It must be a string that is JSON.parse(able).
  -lint-errors-threshold      linter errors threshold in absolute value
  -lint-warnings-threshold    linter warnings threshold in absolute value
  -o, --output                file path to write test results
  -p, --parallel              parallel test execution within each experiment
  -P, --pattern               file pattern to use for locating tests
  -r, --reporter              reporter type [console, html, json, tap, lcov, clover, junit]
  -shuffle                    shuffle script execution order
  -s, --silence               silence test output
  -k, --silent-skips          don’t output skipped tests
  -S, --sourcemaps            enable support for sourcemaps
  -t, --threshold             code coverage threshold percentage
  -m, --timeout               timeout for each test in milliseconds
  -T, --transform             javascript file that exports an array of objects ie. [ { ext: ".js", transform: function (content, filename) { ... } } ]
  -v, --verbose               verbose test output
  -V, --version               version information

As you can see, -coverage-path, -coverage-exclude, -lint-fix, -lint-options etc all show up without a "--" but this is not correct.

I've had a look at the tests for bossy usage and it looks like the options are backwards:

it('returns formatted usage information', (done) => {

    const definition = {
        a: {
            type: 'number',
            description: 'This needs a number'
        b: {
            alias: 'beta',
            require: true,
            description: 'Description for b'
        c: {
            require: true

    const result = Bossy.usage(definition);
    expect(result).to.contain('This needs a number');
    expect(result).to.contain('-b, --beta');

the alias should have --?

But then, this won't work properly if you have options which only have long options - which I would have thought WOULD be the default as it is easier to have unique long items than short ones.

Anyway, getting the usage correct, should be the goal. Any ideas?


This comment has been minimized.

Copy link
Contributor Author

@blacksun1 blacksun1 commented Sep 12, 2016

Also, taken from the bossy README...

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

To use bossy then, does EVERY command line need to have a short version then? This doesn't seem terribly ideal.

@geek geek added the bug label Sep 14, 2016
@geek geek closed this Jan 27, 2017
@geek geek added this to the 12.0.0 milestone Jan 27, 2017
@geek geek self-assigned this Jan 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.