Fix build

[Jean85]

This is an attempt to check the build status on master since it's failing in #399

[Jean85]

I'm unable to reproduce the PHPStan failures locally, I even resorted to run the actions locally with act and I got not errors!

Any pointers?

[Yozhef]

I agree with you, too, I can not understand why the problem is shown here =(

[ste93cry]

Given that the last commit on master is green with an older version of PHPStan, as a starting point I suggest you to try locking in the composer.json the version to something lower than the most recent and greater than the one of the that commit so that we can try to pinpoint at least the release that broke the build

[ondrejmirtes]

The class in question that cannot be found is: Sentry\SentryBundle\EventListener\ErrorListenerExceptionEvent. And it's defined in some really weird way using class aliases in: src/EventListener/ErrorListener.php

I don't know why it doesn't fail locally (doesn't for me either), but it has to be discoverable by PHPStan using this guide: https://phpstan.org/user-guide/discovering-symbols

It's entirely possible it worked thanks to some coincidence because of the order of loaded files. But in order to work 100% of the time, you need to follow what Discovering Symbols says about class aliases. You need to put files that define those aliases to bootstrapFiles. I'm pretty sure that will help.

[ondrejmirtes]

Let's try if it helps: #402

[ondrejmirtes]

Yep, it works.

But what's PHPStan actually telling you here is that if the user of this library adds it to their composer.json and tries to instantiate Sentry\SentryBundle\EventListener\ErrorListenerExceptionEvent, it won't work, because the autoloader doesn't know about it.

Yeah, if they first load ErrorListener and only after that they load ErrorListenerExceptionEvent, it will work, but it's pretty brittle to rely on that.

[ste93cry]

Thank you for putting the time to help us understanding what's wrong. Although the ErrorListenerExceptionEvent class is not meant to be used by third parties, but rather it's there just to support typehinting, what you said makes sense to me. Do you think that a better way to avoid any issue would be move the code with the class aliases to a dedicated bootstrap file that will be autoloaded by Composer? I'm not sure it makes sense given the reasoning for the existence of these aliases I wrote above, but I would still like to hear your opinion

[ondrejmirtes]

@ste93cry Yeah, definitely this commit could be entirely reverted d1b65aa and you could add an aliases.php file with all the class aliases and put it into autoload.files in composer.json. That way it would be picked up by PHPStan too.

[Jean85]

Thanks a lot @ondrejmirtes for solving this mistery for us! It was costing us a lot of wasted time!

[ste93cry]

@Jean85 can you 🙏 update the PR with the changes needed to make it work so that we can merge and unblock all the other PRs?