The reason for the original code was that PHPStan does not analyse and report bugs from 3rd party stubs. So it used stubFiles that's only directly in the project's configuration. If you have some other idea how to isolate those but include the ones from the extension, I'm all ears :)

What are 3rd party stubs?

Aah, you mean for example an application requires a PHPStan extension that has StubFilesExtension, when they analyze their application, those stubs would also be analyzed.

Yeah, that's a tough issue I guess.

Currently it's not perfect either, some users have their project configuration consisting of their own multiple neon files, like https://github.com/pmmp/PocketMine-MP/blob/39b8daeeec3fd2ad9a8593bb15edca65349948bd/phpstan.neon.dist#L1-L11.

So the question is - how to recognize project stub files from 3rd party ones? Just exclude those from $CWD/vendor directory, and analyse everything else? Might be good enough :)

Ok, I tried something. But not sure how to test it.

I can write a unit test for the array_filter logic in DefaultStubFilesProvider. But dunno about the integration test.

A few things to complicate your life:

• composer.json can customize vendor to something else: https://getcomposer.org/doc/06-config.md#vendor-dir
• think about windows and backslashes too 😊

Otherwise I think it should be fine - please test this in practice in your project if it works as expected. You can grab the PHAR file artifact of this PR in Compile PHAR workflow (rename it to phpstan.phar and copy it to vendor/phpstan/phpstan) https://github.com/phpstan/phpstan-src/actions/runs/2401474675

Don't worry about phpstan-doctrine failures, I expected them 😊

BTW the vendor-dir approach could be fixed in more places around the codebase where "vendor" is currently hardcoded 😊

Updated to use the new ComposerHelper to determine the vendor directory. If the composer.json is not found for some reason, it still returns all the stubs because there is no path to filter with.

Awesome, thank you!