Psalm analysis via Phar can break if custom autoloader is used in config

[muglug]

To reproduce:

• create a project with its own autoload="myautoloader.php" configured in psalm.xml which requires vendor/autoload.php
• install an old version of Psalm (e.g. composer require --dev vimeo/psalm:0.3) for that project
• analyse that project using the phar and --root=[project root] where the Phar has a different version of Psalm
• observe hijinks

This is also seen when just running Psalm on a different project with --root (not using phar)

cc @weirdan

[muglug]

Possible solutions are to have Psalm scan that file and remove autoloaders that are already in use before requireing

[weirdan]

I can't reproduce it, probably something is missing from your description.

But I suppose it's the reversal of the #551 ? Now psalm loads it's classes from the project vendor dir?
If so, it could be solved with the namespace prefix hack you mentioned there. There's a new box compactor available that does just that.

Alternatively, psalm could see that it's own copy is available in project vendors, and run that instead (supposedly developers have a reason to not update).

Interestingly enough, PHPUnit seems to work mostly fine in the similar scenario (7.x installed globally, 6.x installed locally). I think that's the consequence of very stable code base.

[muglug]

There's a new box compactor available that does just that.

That would be incredibly ideal. Again, it would just need to ignore the stubs directory.

[muglug]

I'll investigate that - thanks

[weirdan]

box-project/box#31 - this is where it was introduced.