Ignore errors while loading ObjectManager

[ruudk]

It's possible to configure a objectManagerLoader that returns an instance to your configured Doctrine manager.

This works great, and it gives PHPStan super capabilities.

In most cases, you would fetch this object manager from the container from your framework (e.g. Symfony).

But that requires the Symfony container to be compiled and booted.

All good, unless you make a typo in one of your service configurations.

You're left with an internal error when running PHPStan:

<unknown location> Internal error: You have requested a non-existent service "some_service".
while analysing file /Volumes/CS/www/src/SomeFile.php

Run PHPStan with -v option and post the stack trace to:
https://github.com/phpstan/phpstan/issues/new?template=Bug_report.yaml

Found 1 error

⚠️  Result is incomplete because of severe errors. ⚠️
   Fix these errors first and then re-run PHPStan
   to get all reported errors.

Making mistakes is a common thing we do, so having PHPStan crash like this is counter productive.

Even worse, when using the PHPStan integration in PHPStorm, you get error popups every time that this happened.

Since the objectManagerLoader is already optional, we can improve things by catching Throwable's that occur while
including the objectManagerLoader file and then we return null.

To make it easier to debug this problem later, in the diagnostic extension, we show the last error that occurred.

[ondrejmirtes]

I get it, but I'm worried this would make debugging problems harder. Also, a problem in objectManagerLoader would still allow analysis to continue, but with vastly different results, leaving the user wondering why suddenly dozens of problems from the baseline do not occur, or suddenly a bunch of different problems start occuring.

[janedbal]

We have enforced usage of our bin/phpstan (instead of vendor/bin/phpstan), which can solve similar issues. Among other things, we ensure container is built ok before starting PHPStan:

exec('php ' . __DIR__ . '/../src-dev/warmup-kernel.php', $output, $resultCode);
if ($resultCode !== 0) {
    echo("Failed to refresh app Kernel for static analysis\n");
    exit(1);
}

Phar::loadPhar(__DIR__ . '/../vendor/phpstan/phpstan/phpstan.phar', 'phpstan.phar');

require 'phar://phpstan.phar/bin/phpstan';

Asking how to enforce it? Abuse bootstrapFiles:

parameters:
    bootstrapFiles:
        - ensure-proper-bin-phpstan.php

[ondrejmirtes]

@janedbal You could just put this:

exec('php ' . __DIR__ . '/../src-dev/warmup-kernel.php', $output, $resultCode);
if ($resultCode !== 0) {
    echo("Failed to refresh app Kernel for static analysis\n");
    exit(1);
}

Into one of the boostrapFiles instead of using a different executable path for PHPStan.

[janedbal]

IIRC, some things happen too early making this impossible. But not sure this is also the case.

[ruudk]

I get it, but I'm worried this would make debugging problems harder. Also, a problem in objectManagerLoader would still allow analysis to continue, but with vastly different results, leaving the user wondering why suddenly dozens of problems from the baseline do not occur, or suddenly a bunch of different problems start occuring.

I understand. This is indeed the downside of this approach.

I was thinking, what if an extension was able to report an error to PHPStan without it crashing completely.

This way, the user sees at least one error that says something like "There is a problem with the Doctrine ObjectManager: some details". This is a non ignorable error. And then it sees other regular errors.

But at least, the process stays alive, and responds normally.

[ruudk]

@janedbal That approach would still let PHPStan fail / crash hard, making the PHPStorm integration annoying, as it pops up with errors on every file change.

[ondrejmirtes]

So what happens in PhpStorm in this scenario? I feel like the root problem is there. With the newly introduced editor mode, maybe we could do something about it.