Prefix four dependencies during composer install/update (symfony/console, twig, monolog & php-di) #19712
Nice, I just checked out the branch and ran the command and it renamed things nicely.
Ideally, when running composer in the future then it would indeed need to run php-scoper directly as part of the composer command.
Not fully understanding what is meant by this one @diosmosis ?
Would that mean that if someone uses Matomo for WordPress, and they install another Matomo plugin from the Marketplace in their WordPress, and this marketplace doesn't use the prefixed version, then it may cause issues that it could use a wrong vendor version from a completely different WordPress plugin?
I guess if we were to only replace Twig and Monolog this could be fine potentially as it's maybe usually not expected that these libraries would be used too often directly.
I guess from my perspective I just want to keep On-Premise and Matomo for WordPress as similar as possible to not have any unnoticed possible regressions in Matomo for WordPress because they run different code. Looking at the PR I think that doesn't seem to be the case though if I understand it right and would only apply to plugins.
Yes, that could be an issue. If scoping in the composer workflow, then I guess the plugin developer would be forced to use the prefixed namespace otherwise it wouldn't work for a normal Matomo, so this wouldn't happen.
I understand. For a proof of concept I wanted to provide a solution the was as minimal as possible and show that if it turns out to be more complicated to prefix a dependency correctly and predictably, there was an easy way to go back. I also wanted to show its possible to externalize the mechanism and not have it in core if desired. All of this mostly because there was a lot of manual replacing required for twig, though it's probably an exception given it defines so many functions and generates php code that uses them.
Regardless, I can make it part of the composer workflow if desired, should I move forward with that? (I don't have a big opinion here, I think it's workable either way.)
…fix dependency command
…e/bootstrap.php (eg the phpunit entry file)
…dencies from autoload files, since dependencies of prefixed dependencies may not be included
…for prefixed dependencies so unprefixed dependencies of prefixed dependencies will have psr classmaps generated correctly