PHPStan 'No files found to analyse' is considered a problem, even though it may be valid for certain extensions

I also observed the same issue.

A workaround is to just add a blank .module file in the module.

@henokmikre Thanks for the workaround tip! I'm getting this "error" on Features modules that don't have any custom module code, they only have features code/config.

(Full disclosure: I also looked at / commented on 🐛 PHPStan started to fire warnings if no file was scanned, so tests need to contain some empty mock files Fixed .)

I was imagining that it would be nice for modules without any PHP to be skipped by PHPStan, idk what kind of a lift that is. But I don't *think* that's the proposed solution here, or? (If it's not a huge hassle, could someone explain the solution proposed here in slightly plainer language?)

This affects profiles and themes too, in addition to modules. Basically, if happens whenever an extension has no PHP files.

You can build a very elaborate theme with lots of JS/CSS libraries and Twig templates, yet without using any PHP in a .theme file. Such a theme will run into the PHPStan problem here, with no files to analyze.

Quick review of the MR so far (as of comment #2):

I think the right place to check for the "No files found to analyse" situation would be in DeprecationAnalyzer::analyze(). Perhaps by examining $process->getErrorOutput(),

I found an intriguing issue in the upstream PHPStan project: https://github.com/phpstan/phpstan/issues/9410.

The bleeding edge PHPStan now has a "zeroFiles" configuration option, to ignore the situation where there are no files to analyze. This option was only added a couple of days ago, so it's not ready to use yet. If it becomes stable, perhaps the Upgrade Status could inject this option when it runs?

I encountered this problem also, even after updating to 4.2.0. The patch didn't seem to resolve the errors either.

I'm a bit torn on this. First, it is completely valid that no PHP code may be found in an extension. It may be only configuration and composer files shipped in an extension for example. At the same time if there were no PHP files found but they should have been, then that is an error we should report.

That said, it is probably safer to not display this as an error or at least turn it into a warning that integrates well into the UI rather than an error dump like it is now.

For that to happen, we do need to post-process the results, so I think that is a logical direction. However that parsing should not happen on the Drush command level like in the MR but rather where the phpstan error results are stored or processed for being stored.

Proposed a solution that processes this at the IMHO right place.

Test coverage for this is easy because we had 7 empty PHP files to work around this in the tests :D

Re the suggestion above to not run PHPStan if there were no files, I think unless its expensive to run it, I would not avoid it. Otherwise we would need to maintain yet another list of possible PHP extensions to process in Upgrade Status, that is already built into phpstan-drupal. So I think this is fine to recognize it at the end of the result.

Automatically closed - issue fixed for 2 weeks with no activity.