Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Míla Kuchta
    @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
    @faraazahmad
    what does the nargs() function do?
    I looked at the docs, and I dont understand it
    an example or 2 would be really helplful
    ClimbFlyCamp
    @ClimbFlyCamp

    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
    @JKirchartz
    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
    Plastikfan
    @plastikfan
    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,
    thanks.
    Leroy van Engelen
    @lvanengelen
    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
    @lvanengelen
    To clarify: In the example clone is a command, not an argument to -v. Only now seeing how unclear that was sigh
    Christopher Dieringer
    @cdaringe
    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
    @jgornick
    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?
    deleonio
    @deleonio
    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
    @mikl
    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
    @badeball_gitlab
    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
    @badeball_gitlab
    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
    @badeball_gitlab
    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
    @badeball_gitlab
    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
    nugaon
    @nugaon
    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.
    https://github.com/nugaon/furious-commander
    if you like it, please leave a star on the project ^^
    else if ! you like it, leave an issue why
    Jordan Harband
    @ljharb
    yargs already supports subcommands, what does your project offer that's different?
    nugaon
    @nugaon
    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
    @ljharb
    it wraps yargs tho, or it replaces it?
    nugaon
    @nugaon
    of course it doesn't replace, it utilizes yargs the most. check it out!
    Urigee
    @another_malcolm_twitter
    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
    @emme1444
    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?
    Thanks!
    Jordan Harband
    @ljharb
    if you want an option only on specific subcommands, you have to define it in that command's builder
    Emil Walser
    @emme1444

    @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")
        .demandCommand().argv;
    
      console.log(options);
    })();

    When invoked like the following:

    $ <program> hello --help

    it's help output is:

    <program> <command>
    
    Commands:
      <program> hello  description for hello command
    
    Options:
          --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
    @ljharb
    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
    @emme1444
    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
    @ljharb
    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
    @emme1444
    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
    @ljharb
    i think you can probably hide it from the subcommand's help output, but have it still work
    .hide('config') or something