Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
    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

    hi, how is that possible to avoid some kind of automatic replacement within options?

    I passed this value to option: /samples/{id}
    When I read the option value, I get this: /samples/undefined

    How can I prevent it and leave as it is? Thanks!

    Jordan Harband
    why is it using curly braces if it's not trying to interpolate the id?
    Nikolay Lobov
    very nice apps
    i got some questions on fake browser and all that kind of stuff
    and favicon stuff to load webcodecs
    Jonas Amundsen
    Hi, I have a subcommand for which I want to accept arbitrary arguments and pass them along to a subprocess. I'm having trouble with the "accept arbitrary arguments"-part, is this possible?