Run `composer validate` after FixtureManipulator commits its changes

I think only 22 test failing is not bad.

I fixed most of ComposerPluginsValidatorTest as example of what like fixes would be. You can see the errors it had here https://www.drupal.org/pift-ci-job/2602302 →

Ironically, the use of composer validate seems to prevent us from testing invalid real-world composer.json's 😅😳

See: the case that @kunal.sachdev just worked around — see fb324920 and the above MR comments.

That suggests that we need a way to pass the fixture manipulator a known composer validate error, but that we want to proceed anyway, to simulate bad initial sites. Unless … 🤔 … we prevent Package Manager from running on such sites by adding this to the upcoming ComposerValidator that is being proposed in 📌 Create an API for base requirement validators which run before other validators and stop event propagation if they fail Fixed … then we could be confident that this can never occur.

But even then it falls under the domain of this particular validator to test that an exception is thrown. We still would be able to manipulate it this way and then catch the ProcessFailedException to show that we've really thought of all edge cases in our test coverage.

To be discussed — no need to act on this just yet, @kunal.sachdev!

We discussed #7 on the call just now. The direction is not yet 100% clear. For now, can you please restore it but comment it out, and put a comment // @todo Restore this test coverage when ComposerInspector calls `composer validate` — because once that's in, we can figure out a way to continue testing this edge case 😊

Such a big leap forward! 🚀🚀🚀

Needs work for failing tests.

I'll see if I can push this forward.

Looks like we're good :)

OK, well. Since Wim had already RTBCed this, and the only change I made was to fix a quoting bug, and then all tests passed...I think I can restore RTBC and commit this.

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