Document and warn about the dependency of scoped projects on the Composer version

[kkmuffme]

Composer 2.8.4/2.8.5 made some changes to InstalledVersions.php https://github.com/composer/composer/pull/12233/files composer/composer@ee6dc33

which result in InstalledVersions.php now returning the wrong version (= whatever version was loaded first) for packages
Afaik the only fix is to also scope the ClassLoader.php and use a post-dump script to restore the scoped one (since dumping will discard it) and modify autoload_real.php to also load the scoped one (essentially a very similar fix as what is needed for #1036)

However, I remembered you told me there's a test for it: #1043 (comment) e2e 035

Am I doing something wrong or how is that test able to pass? Or did it not run with those composer versions yet at all?

I guess a PR with no changes just to trigger the CI on every new composer release would be helpful to identify any breaking changes?

[theofidry]

Re-opening: there is an issue and it needs to be looked at.

use a post-dump script to restore the scoped one

There is a high chance this won't work. The Composer internal dumped autoload files will not be scoped correctly and ClassLoader is expected to be unique and cross-version to a degree.

Maybe its compatibility is not guaranteed but if that can be fixed somehow by introducing a dep – most likely from the user, but then it requires docs, then this should be mentioned/fixed

[kkmuffme]

The Composer internal dumped autoload files will not be scoped correctly

Which files do you mean?

and ClassLoader is expected to be unique and cross-version to a degree.

Unfortunately, it is only since 2 (afair 2.2) and otherwise can result in a fatal as seen in #1133
There I suggested using composer-runtime-api however as seen with the current issue this is pointless, since composer will break behavior independent of that (2.8.4/2.8.5 did not change composer-runtime-api)

Composer offers a workaround itself without having to scope ClassLoader (the "reload()" method in InstalledVersions.php), however this is something that needs to be called at runtime - and as seen in the 2.8.4/2.8.5 case this also gets broken accidentally.

Therefore the only safe way to ensure there are no conflicts with other existing composer vendors is to fully scope all files, except the "autoload_" ones (since they already have a pseudo-identifier) and excluding only composer classes that are not used at runtime (e.g. Composer Event) - with just 1 exception: composer SemVer class is not bundled but always uses the locally available one (if any), which makes this non-standalone anyway and should actually be removed from InstalledVersions.php too if you want to ensure it runs on systems without composer too.

[theofidry]

Which files do you mean?

The autoload_*.php files.

Unfortunately, it is only since 2 (afair 2.2) and otherwise can result in a fatal as seen in #1133

It has been true since Composer 1.x. ClassLoader. It's just not a hard guarantee. For instance the case you report is basically having an issue with using Composer for which the code had the autoloader dumped 4-5y ago... And would be fixed by having it freshly dumped again. In terms of stability, it's pretty good I would say!

There I suggested using composer-runtime-api however as seen with the current issue this is pointless

I think it's pointless to add to PHP-Scoper itself. Because it won't do anything unless you would be requiring PHP-Scoper as part of a non-dev package... Which would be silly to do and I don't think anyone is doing.

Nonetheless, this can be documented and maybe PHP-Scoper can add a warning about it as well to help raise awareness about it too.

Fundamentally, any symbol that is not scoped and exposed may result in a breakage. As an example, PHPStan scope their code and published that scoped code as a package. However, they do not scope the PHP-Parser API (for practicality). The good practice there would for them to keep nikic/php-parser as a requirement in their published scope package (they don't for reasons, but that would be the practice). Likewise if your app is exposing symbols, it may be a good practice to expose a version or something that you could check to offer a friendly failure.

[kkmuffme]

For instance the case you report is basically having an issue with using Composer for which the code had the autoloader dumped 4-5y ago... And would be fixed by having it freshly

No, for that issue the autoloader was dumped this year - but using composer v1.

I think it's pointless to add to PHP-Scoper itself.

I totally agree (that's why I ended up closing the other issue previously already).

Nonetheless, this can be documented and maybe PHP-Scoper can add a warning about it as well to help raise awareness about it too.

Exactly, that's what I'd suggested too

Fundamentally, any symbol that is not scoped and exposed may result in a breakage

That's clear to you (and since 2 weeks ago to me too :D), but it's not to most of scopers' users it seems -it's popular and used by quite a few popular PHP programs, but I was the first one to report issues with <v2 and 2.8.4/2.8.5 2 weeks ago, even though composer 2 (as for the composer v1 backwards compat issue) was released 5 years ago and 2.8.4/2.8.5 was released 1 year ago. Which indicates that people aren't actually fully aware how their scoped code behaves when used with different versions of composer used in the same application/runtime as the scoped code.

To quote that plugin's author from stayallive/wp-sentry#232 (comment)

Bit sad to see that this is how the autoloader worked when also scoping... have always assumed it was all self-contained. TIL

Therefore I guess, making this clear in the docs is a good idea.