Where communities thrive


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

    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
    @ljharb
    why is it using curly braces if it's not trying to interpolate the id?
    Nikolay Lobov
    @four-by-two
    hiho
    @xyfir
    very nice apps
    i got some questions on fake browser and all that kind of stuff
    and favicon stuff to load webcodecs
    Jonas Amundsen
    @badeball
    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?