boolean silently converts string to true

[tttp]

Hi,

me again, in my quest to idiot proof the cli ;)

so I have two params, one foo and one bar

const argv = require("minimist")(process.argv.slice(2), {
  string: ["foo"],
  boolean: ["bar"]
});

if I run it with

--foo alice --bar bob

I get

• argv.foo = alice
• argv.bar=true
• argv._ = ["bob"]

as expected

however, if I run it with

--foo=alice --bar=bob

I get

• argv.foo = alice
• argv.bar=true
• argv._ = []

so a --bar=string is silently converted into --bar = true

is there an option to catch these conversions ?

[ljharb]

That's surprising; both forms (equals sign, or space) are standard for double-dashed args, and I'd strongly expect and prefer always using the = to avoid ambiguity.

In other words, both of those should be indistinguishable imo, and it's a bug that they aren't.

[ljharb]

cc @shadowspawn for your thoughts

[tttp]

--silent A B is IMO correctly doing argv.silent=true (if defined boolean)and argv._ = ["A","B"]
I understand where --silent=A being converted as argv.silent=true (if defined as boolean) comes from, but IMO making it surprising

[ljharb]

if --silent is defined as a string, then --silent A should be the same as --silent=A imo - only if silent is defined as a boolean should it not take a value.

[tttp]

@ljharb, exactly, when set as boolean, --x A and --x=A behave differently.

I understand that if set as boolean it can't take a value, what is non-intuitive is that it does silently discard the string if --x=A but process it as a separate args._. if --x A

and what is the most difficult for me is that minimist allows me to identify and raise an alert if --x A, but doesn't allow me to identify that a user wrongly wrote --x=A (where x being boolean)

[ljharb]

ahh, i see what you mean.

I would expect --x A is two args when x is a boolean, and --x=A would eventually lead to a validation error, as you say.

[shadowspawn]

me again, in my quest to idiot proof the cli ;)

Minimist is not the right tool for that job. But it is fun exploring anyway! 😆

is there an option to catch these conversions ?

Short version: no.

In more common cases, the behaviour with boolean options is fairly self-consistent. Assigning a value to a boolean option on the command-line means Minimist silently processes it.

var parse = require('minimist');

const argv = parse(process.argv.slice(2), { 
    boolean: 'flag',
    string: 'w'
});

console.log(argv);

% node index.js             
{ _: [], flag: false }
% node index.js --flag
{ _: [], flag: true }
% node index.js --flag true
{ _: [], flag: true }
% node index.js --flag false
{ _: [], flag: false }
% node index.js --flag other
{ _: [ 'other' ], flag: true }
% node index.js --flag=true 
{ _: [], flag: true }
% node index.js --flag=false
{ _: [], flag: false }
% node index.js --flag=other
{ _: [], flag: true }

[ljharb]

The "silent" part is what feels like a bug to me. It should either reject it or preserve "other" somewhere.

[shadowspawn]

(Thinking about that...)

[tttp]

A somewhat related issue
#2

it might be enough to offer an option mistyped = (key, value) => {} working similarly to unknown ?

[shadowspawn]

Thinking about example --bar=bob where an option argument is explicitly given to an option declared as boolean.

Possible approaches, and my reservations, leading to a more radical suggestion.

1. reject (say throw): Minimist current accepts anything, so certainly a breaking change.

2. preserve: the value could be preserved directly like { bar: 'bob' } so the issue could be detected by the author. It isn't likely to be a common error. Amusingly, a naive "truthy" test of bar would return true anyway!

However, this would be a change in existing behaviour to make it possible to detect a special case, without handling the special case. So cost/benefit ratio is dubious.

3. mistyped(): I don't think this is common enough to justify an opt-in author supplied handler.

4. status quo: not satisfying, but likely a rare problem in real world use!

5. add .strict(). This would be opt-in so does not break existing users. Strict mode throws for:

• boolean option used with an explicit option argument other than true or false
• string option used without an option argument
• unknown options, unless there is an unknown handler (in which case left to author)

I feel this might address the underlying problem more directly, which is validating the user supplied arguments with the author supplied configuration.

Edit: thinking about API, would be strict: true rather than .strict().