Why a wrong args parser?

tl-dr; I didn't wrote a parser.

Instead, I used regular expressions for extracting values, flags and other kind of parameters from a string or from an argv-like array.

I've tried commander, minimist, yargs, etc. but no one fulfilled my exact requirements, e.g.

conststr='/ _csrf=`token` --json accept:"text/plain; charset=utf8" -- x';constargv=['/','_csrf=`token`','--json','accept:text/plain; charset=utf8','--','x'];

Both values are representing the same input, the former can be taken from any source while the latter is usually provided by process.argv.slice(2), etc.

Most importantly: these modules will won't work with a string as input.

wargs will do and return: _, raw, data, flags and params.

{_: ['/'],raw: ['x'],data: {_csrf: '`token`'},flags: {json: true},params: {accept: 'text/plain; charset=utf8'},}

Hint: It suits -and feels- very well on a repl for making http requests. ;-)

How it works

wargs use getopts to understand regular flags, -short or --long, etc.

Also it will collect key:value and key=value values as params and data respectively.

wargs('-x').flags.x;// truewargs('--x').flags.x;// truewargs('x:y').params.x;// ywargs('x=y').data;// { x: 'y' }wargs('x y')._// ['x', 'y']wargs('--x-y',{camelCase: true}).flags;// { xY: true }wargs('-x y',{format: v=>v.toUpperCase()}).flags;// { x: 'Y' }

Options

• format — function decorator for all values
• camelCase — normalize keys from --camel-case to camelCase
• alias, boolean, default and unknown — those are given as is to getopts

Fun facts

• When I was looking for a name for this module I found that xargs, yargs and zargs already existed
• I'm totally wrong on calling this module a "parser" for command line arguments, don't be rude
• Finally, I discovered that wargs are a thing from GoT