Remove FixtureManipulator::modifyPackage() last usage

I think this will happen automatically as part of 📌 Remove our runtime dependency on composer/composer: remove ComposerUtility Fixed ? Let's keep this around just in case that's not true!

going to mark this as core-mvp. We could argue that it is not but if we don't remove \Drupal\fixture_manipulator\FixtureManipulator::modifyPackage then we also can't remove \Drupal\fixture_manipulator\FixtureManipulator::setPackage which is 100 lines long and not really well documented. So I think it would take more time to help a core committer review that function than it would to just make sure it is gone.

Another option would be to move the logic needed to update a package, not add or remove from FixtureManipulator::setPackage directly into modifyPackage() because it would much more understandable.

In any case I don't think want to try to get a core review of the current \Drupal\fixture_manipulator\FixtureManipulator::setPackage. It served us well when we needed it but 👋✌️

Looks like at least some of the failures were independently discovered in the core MR too, and are being worked on here: #3346628 — see #3346628-9: ComposerPluginsValidatorTest fails with pcre.backtrack_limit=1000000 set → .

Next up: rebasing on origin/3.0.x (rebase instead of merge since nobody has reviewed this yet anyway) to see if the failures remain the same.

🐛 FixtureManipulator should only use Composer commands, rather than manipulating JSON directly Fixed is in, continuing here…

Based on the past ~2.5 hours of research, it looks like composer does not actually support multiple path repos providing the same package, but different versions of it. Either composer update --lock complains first (I can work around this by using --append to add the new version last), or composer require complains (which then says that the first one is “canonical” despite my having specified canonical: false). I need a break from this debugging saga, so I just pushed a bunch of commits, but I have not been able to figure out how to get \Drupal\Tests\package_manager\Kernel\SupportedReleaseValidatorTest to pass … 😬

I’m back.

IMO this is ready. I just posted ~10 comments for the reviewer/committer — who happens to be @phenaproxima today because @tedbow is out 😄

I'm hopeful that that will address all of @phenaproxima's questions so he can comfortably commit this!

Wim Leers → credited phenaproxima → .

This mostly looks great, I think. I'm really glad we're finally burying the direct modification of underlying Composer data. This is magnificent and I can't wait to land it.

I think some doc comments could be slightly improved. There is one question that is blocking, because it seems to contradict documented behavior.

🏓

And FYI: #3342227-22: ScaffoldFilePermissionsValidator should use ComposerInspector instead of ComposerUtility → has a patch that will be green once this lands! 🤓🥳 (Re-test it after this is in!)

Yeah, you know...I can't find anything to complain about here, really. It's magnificent.

Merging when tests pass.

This also unblocked 📌 Explicitly validate lock files everywhere: `composer validate --check-lock` Fixed 😊

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