colors!

[fulmicoton]

That would be awesome if we could get colors in the usage description.

[nexdrew]

@fulmicoton Great suggestion! My opinion is that content decoration should be handled outside of yargs, so the API can stay focused on functionality. That's why I created yargonaut.

Originally it only supported decoration via figlet fonts (ASCII Art), but, based on your suggestion, I spent some time today adding support for chalk styles as well. With the latest version of yargonaut (1.1.0), you can now colorize the yargs-generated text for your CLI! (I can't believe I didn't think of this before! 😉)

Please give yargonaut a try and let us know what you think, one way or another. Hopefully it gives you the flexibility you're looking for. 😎

Note 1: You'll probably want to focus on the helpStyle(), errorsStyle(), and style() methods.

Note 2: For best results (and full locale support), you should require('yargonaut') before you require('yargs').

[bcoe]

@fulmicoton I'm with @nexdrew on this, colors are a great extension to yargs but I think we should keep it out of core. Seem reasonable?

[bcoe]

Perhaps we could add a section to the README that has nifty related projects?

[nexdrew]

I thought of that but didn't want to shamelessly advertise my module or make it seem like yargonaut is officially endorsed by yargs. I'd be happy to add it though.

Personally I think it'd be cool to build support for plugins into yargs, but I haven't come up with an API for this yet. Was planning to bring it up when we talk about commands/V4. Not sure there are enough use-cases to warrant it though.

[fulmicoton]

Sorry for not replying earlier. Thank you so much @nexdrew for picking up on that so quickly. I will try that out later today.

About the discussion of whether to put that in yargs or yargonaut, whatever works for you guys :)

[bcoe]

@nexdrew be as shameless as you see fit :)

[fulmicoton]

@nexdrew Thank you! It works fine for me. I wondered if it is possible to apply a specific color to option (-f, --file) and commands.

[nexdrew]

@fulmicoton The official answer is no, because yargonaut can only customize the locale-specific strings baked into yargs. Option keys, command names, and descriptions are defined by the consumer module, and so are not subject to internal y18n lookup.

However, you can hack it via "hidden" commands and options, if you really want to. The code is pretty ugly, and you'll have to duplicate some yargs validation logic, but it would look something like this:

var yargonaut = require('yargonaut')
var chalk = yargonaut.chalk() // could also just require('chalk') yourself

var argv = require('yargs')
  .command(chalk.green('add'), 'Add a file')
  .command('add', false, function (yargs) {
    // need option validation here
    console.log('adding')
  })
  .command(chalk.red('rm'), 'Remove a file')
  .command('rm', false, function (yargs) {
    // need option validation here
    console.log('removing')
  })
  .demand(1)
  .option(chalk.yellow('f'), {
    alias: chalk.yellow('file'),
    describe: 'The file to add or remove',
    type: 'string'
  })
  .option('f', {
    alias: 'file',
    type: 'string'
  })
  .help('h').alias('h', 'help').wrap(null)
  .argv

Your best bet is probably to just color the descriptions instead of the options/commands themselves, like this:

var yargonaut = require('yargonaut')
var chalk = yargonaut.chalk()

var argv = require('yargs')
  .command('add', chalk.green('Add a file'), function (yargs) {
    console.log('adding')
  })
  .command('rm', chalk.red('Remove a file'), function (yargs) {
    console.log('removing')
  })
  .demand(1)
  .option('f', {
    alias: 'file',
    describe: chalk.yellow('The file to add or remove'),
    demand: true,
    type: 'string'
  })
  .help('h').alias('h', 'help').wrap(null)
  .argv

That's about all you can do for now.

[binarymist]

It seems that yargonaut is applying some extra non printable characters? require('yargonaut').style('green');

How would you go about applying an rgb hex to the headgins alone (Commands, Options), and then a different styl to the command and a different one to the options?

Thanks.

[binarymist]

I've stepped into the lib and it doesn't apper to do anything, then at some later stage when help is called, some of the values are coloured. If I pass in the keys Commands and Options, they are never styled.

Clues?

[binarymist]

I can't seem to find a usage: key?

[binarymist]

Hmm, seems like yargonaut can't find yargs, any idea how this actually works?

[binarymist]

Although if we have the two imports the opposite way around to what the docs specify, we get a yargs instance.

Also wondering how backgrouns are done as can be seen at chalk?

[binarymist]

If we colour the options like so:

  const cliArgs = yargs
  .usage(`Usage: $0 [command] [option(s)]`)
  .commandDir('cmds')
  // This overrides the --help and --version and adds their aliases  
  .options({ 
    [chalk.bold('h')]: {alias: chalk.bold('help'), describe: 'Show help'},
    [chalk.bold('v')]: {alias: chalk.bold('version'), describe: 'Show version number', type: ''},
    'a': {alias: chalk.bold('about'), describe: 'Show about screen', type: ''},
  })
  .strict()
  .epilogue('For more informatiion, find the manual at https://docs.purpleteam-labs.com')
  .argv;

we get duplicate options along with -- in front of them instead of -:

How is this supposed to work?

Also how can we get rid of the [boolean] on the default help and version, as it's meaningless unless we had something like --help true

We also can't have styled help in any way, if we do, the listing just gets duplicated.

[nexdrew]

@binarymist Hi 👋 unfortunately I am no longer maintaining yargonaut and it may be incompatible with the latest version of yargs. Please read this for more info.

[binarymist]

Ok, so basicallly the answer is to move to sywac. Although it's really anoying as I've just spent a couple of days on this, I do understand your reasoning and it makes sense. I've seen quite a few times project founders do this, and the second, third project in the same catagory inherits all the learnings (same mistakes not made) from the former projects. I have a few questions:

• There are very few colaborators on sywac, in fact, you're essentially the only one. What do you think the reason for this is?
• How long are you planning on maintaining sywac?
• What are your thoughts for why the uptake has been so slow on sywac, I've also never heard of it before now, which is dissapointing
• Does sywac resolve all the issues I've mentioned above?
• In the comparison matirx it states that Command Executiion is awaiting completion, does that mean it's not done, or does that mean awaits in the technical sense?
• Does sywac allow for removing [boolean] for -v and -h?
• Does sywac styling support everything in chalk, rgb/hex values, etc?

I'll create a branch and have a crack at sywac, the docs look good on first appearance, although a lot missing. Do you have a contibuting guide?

Update. Spent a day on sywac and have ported all of my yargs code. So far it's been an easier setup than yargs. The API is more intuitive, and it's clear to see that @nexdrew has learnt a lot from yargs and applied the learnings to sywac. At this stage the sywac docs are a little lacking, but if you've used yargs, the migrations is intuitive and painless. All the things I was struggling with in yargs are no longer an issue with sywac. Well done @nexdrew !

[onury]

I agree that content & styles should be handled separately.
But yargs' API makes it almost impossible to style the output properly.
At least some API should be added to "help" enable colors.

EDIT:
As a workaround, I'm doing this:

yargs.updateStrings({
        'Options:': chalk.blue('Options:')
    })
    ...

But this would disable auto-locale for the updated string, I guess.
It would be nice to have specifiers, e.g.:

yargs.updateStrings({
        'Options:': chalk.blue('%$')
    })
    ...

But still you cannot style lots of other parts...

[davidkjackson54]

Has sywac been abandoned? I don't see any movement on it for over 6 months and the doc is minimal.

[nexdrew]

@davidkjackson54 No, sywac has not been abandoned. It's at a relatively stable point and I use it for all my own CLIs. I just haven't had time to work on the docs or road-mapped features in a long time, and no one else has volunteered to help. I am still maintaining the project and will continue to do so for the foreseeable future.

[davidkjackson54]

Thanks that is great to know. I have a need to be able to support positional parameters for example:
cli.js jobs status --jname

where jobs and status are both positional parameters and jname is a required subparm.
I know yargs can handle this but I haven't been able to find any documentation or examples on how to accomplish this in sywac. I also need to have the help auto generated for this. So a user could enter
cli.js --help
cli.js jobs --help
cli,js jobs status --help

Are there any samples of how i can accomplish this available?

[nexdrew]

Are you asking for yargs or sywac? If you are asking how to do this in sywac, please open an issue there.

[davidkjackson54]

Done