-
Notifications
You must be signed in to change notification settings - Fork 108
Ignore errors while loading ObjectManager #662
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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.
868ae57 to
4cd7002
Compare
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.
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
@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.
IIRC, some things happen too early making this impossible. But not sure this is also the case.
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.
@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.
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.
This is the error we're seeing in PHPStorm:
Screenshot 2025年06月02日 at 15 08 27@2x
Uh oh!
There was an error while loading. Please reload this page.
It's possible to configure a
objectManagerLoaderthat 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:
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
objectManagerLoaderis already optional, we can improve things by catching Throwable's that occur whileincluding the
objectManagerLoaderfile and then we returnnull.To make it easier to debug this problem later, in the diagnostic extension, we show the last error that occurred.