ComposerInspector::validateProject() passes unnecessary flags to `composer validate`

Reviewing

This looks good to me +1 on not adding any extra test.

1. --no-ansi definitely was a bug — I intended the opposite 🙈
2. --no-interaction: I disagree, it's not because it currently doesn't ever interact, that it won't in the future either. It's specifically listed in the output for composer help validate, so I think we should keep it.
3. --no-cache: I disagree, same reasoning as above.

Summarizing my concerns in #10: prudence about how the behavior of our dependency Composer will evolve.

It's specifically listed in the output for composer help validate, so I think we should keep it.

I could be wrong but I suspect this is actually a generic option inherited from Symfony Console.

--no-cache: I disagree, same reasoning as above.

I disagree with your disagreement :) I once again suspect this is a generic option that Composer adds to its command classes; I don't see how composer validate would ever have use for a cache. If it ever does, we can restore this flag when we need it, and thus have documented and explicit reasoning (as well as a comment) for why we restored it.

To further support my point here: the validate command has no usage of the word "cache": https://github.com/composer/composer/blob/main/src/Composer/Command/Vali...

Oh, and another reason why we shouldn't add --no-interaction right now: as I understand it, --no-interaction will suppress any interactive prompts in favor of the default values for those prompts.

If composer validate becomes interactive in the future, we won't know the defaults for those prompts, which means that --no-interaction might inadvertently send us down a wrong path.

Well well well … \Composer\Command\ValidateCommand has zero mentions of "cache" or "interaction".

IOW: Composer's help output is lacking in empathy for its end users 😢😬

EDIT: crossposted with #13 and #14 😬 Clearly @phenaproxima and I agree now 😄

Automatically closed - issue fixed for 2 weeks with no activity.