Undo (CLI) arguments

[tfrommen]

Hey there.

It would be great to make sure some (CLI) arg is not set.
Meaning, with a ruleset that contains <arg value="x"/>, I would like to be able to unset that flag—both via CLI or from another ruleset that extends the other one.

Real-life example:
Imagine some app that runs phpcs, and provides some fancy and interactive output on some web UI. This might break if it expects just the output (in whatever format), but then the ruleset also contains the -p flag to show progress. If only the app could undo the progress flag...

The main two questions are now if you want such functionality, and, if yes, how best to implement it.

One way to do so is to provide uppercase flags. This is done by some CLI tools, while others might have completely different things attached to, for example, -a and -A. And yet others totally don't care about casing, and treat -A as if it was -a, and vice versa.

So, with negative uppercase flags, a ruleset containing <arg value="sp"/> would not display progress, if called via CLI with -P. Also, if the ruleset contained <arg value="P"/>, it would also not display progress, irrelevant if any other referenced ruleset would set it.

Does that make sense?

I already had a look at how args are being processed (here and here), and while it would require some changes, of course, I'm positive they would only be internal, not breaking any current behavior. Unless people already are using uppercase flags in custom extensions. (PHPCS itself is not using any uppercase flags so far.)

Thanks already in advance for your time. ✌️

[gsherwood]

The way I've approached this previously is to just provide new CLI arguments to counter existing ones, if I think they might need to be countered.

For example, if a standard is using -n to hide warnings, you can use -w to show them again. Or if someone is using -p for progress (or the verbose options), you can use -q to make PHPCS run quietly.

But this is still an interesting idea. I just don't think it could apply to all the single letter options and it would deprecate -w and maybe -q I guess. I think there needs to be some thought about what happens when custom standards include uppercase options as well as they can conflict with options provided on the command line. Maybe uppercase reversal options are only available on the CLI.

[tfrommen]

Oh, right. Having a completely different flag undo what another one would do, is another option. One I wanted to mention too, but forgot.

However, I don't think this is always easy or appropriate, or rather the exact counterpart of some other flag. In the -p—-q example, "progress" and "no nothing" would not really be the exact opposites, while "progress" and "no progress" would be.

That said, having the possibility to use (uppercase or not) negative flags only via command line would totally work in my case. It might just also be nice to be able to do this from a ruleset that references another one. Not a priority for me personally, but valuable in general.

Thinking out loud, the -q flag could be deprecated, and a new --quite could be introduced. This would behave like the current -q, meaning it would not render progress, nor verbose stuff. But then there would also be -P and -V (no need for -VV or -VVV, of course!) that would undo the lowercase versions of them.

In essence, all single-letter flags would do just one thing. One thing, you easily can undo. Except for -d, which is a bit odd anyway, and would better be --ini-set key [value], if you ask me. That is aligned with --config-set key value.