PHPStan failed with "No files found to analyse"

Hm, have not seen this before :/ Can you try https://github.com/mglaman/drupal-check on the same module to see if that worked? Thanks!

Progress bars always print to stderr

            $postFileCallback = function (int $step) use($errorOutput, &$progressStarted, $allAnalysedFilesCount, $filesCount, &$fileOrder) : void {
                if (!$progressStarted) {
                    $errorOutput->getStyle()->progressStart($allAnalysedFilesCount);
                    $errorOutput->getStyle()->progressAdvance($allAnalysedFilesCount - $filesCount);
                    $progressStarted = \true;
                }
                $errorOutput->getStyle()->progressAdvance($step);

Based on the above output, though, the raw errors were returned due to an unexpected error. See https://git.drupalcode.org/project/upgrade_status/-/blob/8.x-3.x/src/Dep...

The screenshots look strange because if there is valid JSON returned, we take that as a valid return value. Visually looking it does not seem like what you got is invalid JSON?! Either way, if you still have sites to port, it would be great to try with 8.x-3.11 which changes how phpstan is executed.

I got the same problem and found the unexpected <?php tag from phpstan result.

It looks like a similar problem I just met: I have a custom theme that extends a base theme but does not include a single line of PHP, so when running an upgrade_status 4.0 scan, I get this error

PHPStan command failed:
/opt/homebrew/Cellar/php@8.1/8.1.21/bin/php /Users/fgm/src/OSInet/org/riff/blog/./vendor/bin/phpstan analyse --memory-limit=1500M --error-format=json --configuration=/tmp/upgrade_status/deprecation_testing.neon /Users/fgm/src/OSInet/org/riff/blog/web/themes/osinet/riffblogt

Command output:
Empty.

Command error:
! [NOTE] No files found to analyse. [WARNING] This will cause a non-zero exit code in PHPStan 2.0.

Adding an almost empty (theme).theme file fixed the issue for me.

That there was no file found to analyse sounds like a legitimate problem. At least it does not say everything was ok because there was nothing to check if it was ok. I guess for themes that could be a realistic scenario that no PHP file was found, but it would only be reasonable for modules very rarely. Should we have a special case for this situation? We would still need to somehow surface that there was no file scanned, but maybe a nicer error handler for this case?

I think one could imagine a module only consisting of libraries, so with a mymodule.libraries.yml and a bunch of CSS / JS files pointed by those, so no PHP code either.

That's probably not common but does not have to be an error. It's a bit similar to the "theme extends a base theme, only changing CSS / JS".

Let's focus this issue on the no files case then. The others don't seem to have more info on why they would happen.

However how we represent this situation is a question. That no file was found could be an error or it could be a legitimate thing to ignore. So we should IMHO report it, but maybe not as a raw error, but more like a warning level? It would still show it as one problem to resolve though, so those that want to make that go away would "need to" add an empty module file or somesuch for the error to go away. We can maybe discourage that in the message?

FWIW, I'm having the same issue. I've got a module with only my_module.info.yml and my_module.libraries.yml files, so I get the "No files found to analyse" warning. I created a temporary my_module.module file, and I was able to validate that the module is indeed D10-ready.

I agree with Gábor -- maybe this "no file" issue can be a warning or even an info level. And place it in a "Compatible with next major Drupal core version (with caveats)" category instead of "Fix manually". My thinking is that a module with no executable code is technically compatible with Drupal 10...

1. I am getting the error for PHP Stan command failed, as mentioned in the issue description, but not getting any error related to "No files found to analyse".
   
2. When I debugged the analyze method of the DeprecationAnalyzer class, I found that the Process class is not returning output on line 373, and as a result, we are getting null in $json.
   
3. Further, the condition check implemented for checking any JSON errors is returning true, and it is showing errors, although the PHP stan command is being executed successfully without any errors.
   

Anyone can please look into this and implement a solution to resolve the issue mentioned above.