Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

yargs-parser 'strip-dashed' option is incompatible with yargs option names #273

Open
adjkilgore opened this issue May 28, 2020 · 1 comment

Comments

@adjkilgore
Copy link

When specifying a command option (e.g. component-version), it is automatically converted to camel-case in the parsed object (i.e. componentVersion).

When using the strip-dashed option to remove the non camel-case version, yargs fails validation, because the non camel-case option is missing.

Related Code

yargs
    .commandDir("./commands", {extensions: ["js", "ts"]})
    .demandCommand()
    .option("verbose", {description: "enable verbose logging for the command"})
    .help()
    .wrap(72)
    .parserConfiguration(
        {
            "sort-commands": true, 
            "strip-dashed": false, 
            "strip-aliased": true
        })
    .argv;

import { Argv } from "yargs";

exports.command = "prerelease <component>";

exports.desc = "manage deployable artifacts";

exports.builder = (yargs: Argv) => {
    
    yargs.positional("component", {
        type: "string",
        description: "The name of the component to deploy",
        demandOption: true
    });

    yargs.option("component-version", {        
        type: "string",
        description: "The version of the component to deploy",
        demandOption: true,
    })
};

exports.handler = (args: any): void => {
    console.log(args) // expect {component: "name", componentVersion: "1.0.0" }
}

Instead I get

Missing required argument: component-version

My expectation would be that parsing succeeds, and yargs recognises the camel-case option.

@bcoe bcoe transferred this issue from yargs/yargs May 29, 2020
@shadowspawn
Copy link
Member

I suspect this is a problem in yargs rather than yargs-parser, but I have not tried reproducing yet. It sounds very similar to issues I looked into with interaction of coerce and configuration: yargs/yargs#2308

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants