Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
    Míla Kuchta

    Hi guys,

    I have a problem no other command line parsing library I've explored (probably) supports and since the generality of yargs, maybe you have some solution for it, but I can't really tell as from many options you provide, I'm a bit lost :).

    I want to get a list of possibly multiple commands with arguments in a row as defined on the command line, so that I can build from it a "functional pipeline", that will be applied to some array/iterator/stream.

    Is this case somehow solvable with yargs?

    Many thanks...

    Syed Faraaz Ahmad
    what does the nargs() function do?
    I looked at the docs, and I dont understand it
    an example or 2 would be really helplful

    Had a quick question. I am building a CLI using yargs and want to give users the options to add their own commands in a specific folder. I know I can use the following to accomplish this:

    .commandDir(path.join(process.cwd(), 'commands))

    This works great when the folder exists in the project, but if it does exist I get the following error:

    Error: Error: ENOENT: no such file or directory, scandir 'DIRECTORY_PATH'

    is there a way add the command directory ONLY if the directory exists?

    Joel Kirchartz
    hey, I'm trying to use commandDir here in /bin to load commands from /lib but it seems the positional arguments only work for the first command and not the other ones? am I doing something wrong? https://github.com/jkirchartz/pos2tracery
    Hi, I'm having trouble writing typescript yargs unit tests. Can anyone help with this issue: https://stackoverflow.com/questions/60038269/how-to-correctly-unit-test-yargs-in-typescript,
    Leroy van Engelen
    Hi, I am wondering whether yargs supports command lines as the following: myprog -r repo -v clone -p proj -a, i.e. having arguments (-r, -v) that are available for each command and are specified before it and arguments that are only valid for a specific command (-p, -a). Similar to https://git-scm.com/docs/git. I tried using something like yargs.option(...).command(...) but that did not seem to work.
    Leroy van Engelen
    To clarify: In the example clone is a command, not an argument to -v. Only now seeing how unclear that was sigh
    Christopher Dieringer
    Hey all. Is there a known working recipe for nested completions? Suppose I have cmd a [a1, a2,a3]. When I punch in subsequently cmd a a1 I continue to get completions as a1 a2 a3 even if I did a .completion(a1, ...) with higher specificity options
    Joe Gornick
    Hey folks, if writing CLIs with yargs, is there a recommended way to do any sort of logging? Is it just a matter of use npm/debug, or npm/winston?
    Hello together
    I have detect a vulnerability in https://snyk.io/test/npm/yargs-unparser/1.6.0
    I would like to help you.
    Mikkel Høgh
    Is it just me, or is http://yargs.js.org/docs/ missing its content?
    https://raw.githubusercontent.com/yargs/yargs/v15.4.1/docs/api.md returns 404 for me
    Jonas Amundsen
    Hi, has anyone attempted to use the non-singleton interface with es modules?
    I don't understand the esm platform shims at all. I'm trying to use yargs in node and not the browser, I am making a CLI utility after all, why must I shim anything?
    Ultimately, my goal is to create a utility, bundle it with rollup and distribute a single executable, while using typescript, but that turned out to be easier said than done
    Jonas Amundsen
    Hmm, given that the module-path in package.json is and was wrong since release, I guess not so many are doing this just yet
    Jonas Amundsen
    In lib/platform-shims/esm.mjs:13 you do import y18n from 'y18n', but y18n doesn't have a default export. You can see in node_modules/y18n/build/lib/index.js (after having installed yargs obv), that it only export function y18n(..) {..}
    Consuming the esm-build of yargs using eg. rollup just doesn't work atm (it respects the "module" field of packages recursively)
    Jonas Amundsen
    It appears that the esm-build exports a non-singleton interface, while the cjs exposes a singleton interface. Given that I've understood it correctly, this makes it difficult to consume @types/yargs, as it assumes one of them
    I realize that there probably went a ton of work into yargs/yargs#1708 and I appriciate that, but I wish you would fix the itsy bitsy remaining pieces to make this compatible with eg. rollup
    Hello everyone!
    I have developed a framework for yargs, that is really easy to use, supports subCommands (which is one of the thing why a lot of people use yargs), and it was intended to be testable by default.
    if you like it, please leave a star on the project ^^
    else if ! you like it, leave an issue why
    Jordan Harband
    yargs already supports subcommands, what does your project offer that's different?
    yep, that's why I wrote the people use yargs in the first place. it approaches the app structure for commands from a different perspective and thereby make it easier
    Jordan Harband
    it wraps yargs tho, or it replaces it?
    of course it doesn't replace, it utilizes yargs the most. check it out!
    Hi everyone! Is there a way to avoid the double hyphen when I'm calling npm script with yargs? Let's say I have this script "test mocha 'tests/**/*.test.js'" in my package.json. As far as I understand I can pass some custom params only like this npm run test -- --myCustomArg=foo. Can I somehow shorten it to be script --yargs ?
    Emil Walser
    HI! How can I disable global options from appearing within all sub-commands (from being global)? Like when I use .option on yargs itself. It makes those options global and they exist on all sub-commands as well as the top-level executable. I do not want this behaviour. How do I accomplish this?
    Jordan Harband
    if you want an option only on specific subcommands, you have to define it in that command's builder
    Emil Walser

    @ljharb I think you misunderstood. or I miss-explained. Consider the following example:

    const yargs = require("yargs");
    (async () => {
      const options = await yargs
        .option("config", {
          type: "string",
          alias: "c",
          //global: false,
        .command("hello", "description for hello command")

    When invoked like the following:

    $ <program> hello --help

    it's help output is:

    <program> <command>
      <program> hello  description for hello command
          --help     Show help                                             [boolean]
          --version  Show version number                                   [boolean]
      -c, --config                                                          [string]

    In my optinion the --config options should not appear on the hello command. As i understand it, this is documented as options being "global" by default. But setting global to false does not help.

    Thanks for the help!

    Another example is the fact that the --version option also exists on the sub-command. Which is not desireable.
    Jordan Harband
    whether they should or not is really a separate debate
    they do, because everything on the top-level yargs instance is global
    why wouldn't you want --config on everything?
    (global: true doesn't mean this, what it means is that it will be hoisted above middleware. everything is global:false by default)
    Emil Walser
    because, to me, it just doesn't make sense. it belongs to the top level executable. and it creates confusion. what if sub-commands need the same option name? etc..
    a ok. oh well
    Jordan Harband
    subcommands belong to the top-level executable also
    if they didn't, they'd be independent top-level executables, not subcommands
    subcommands are not for just grouping unrelated things
    that's not unix-like :-)
    Emil Walser
    we just have different mental models. i just prefer it different
    also I didn't say anything about unix-like
    i mean yes they are related between depths, and of course I would need the values of options specified on levels above, but I don't think they should be represented in the below commands' help output. nor do I think they should be able to be specified on below commands on the command-line. again just preferences
    Jordan Harband
    i think you can probably hide it from the subcommand's help output, but have it still work
    .hide('config') or something