Prepare for phpstan-drupal:^0.12.0

Yeah we decided to bundle up all the neon files because you can place a module at almost an arbitrary location. It could be under sites/ or modules/ or profiles/ and then any depth of subdirectory, etc. So we would need to somehow traverse up the tree and find the vendors in hopefully the same tree somewhere and read them up from there. I recently seen that there is still the capability to include PHP logic from neon files to include more neon files, so maybe that would have been a possibility. But it did sound a bit fragile in case we happen to find the wrong file, etc. So this felt safer even though more maintenance. That may or may not hold true at this point :D

I looked at the fails and it fails on a lack of $result in DeprecationAnalyser::runPhpStan(). Yeah that code should be better and not try to use $result when it throws an exception of course.

The exception logged is: Nette\DI\ServiceCreationException: Service of type PHPStan\Drupal\ServiceMap: Parameter $drupalServices in __construct() has no class type hint or default value, so its value must be specified. in /var/www/html.original/vendor/nette/di/src/DI/Resolver.php:514

Attempting to sync this up with the source neons, as not all the pieces happened in our files AFAIS.

Found https://github.com/mglaman/phpstan-drupal/commit/20aa2a70acad5f3d6c7e6e2... among other things that was not yet reflected in the patch above.

For that to work we'll need to dynamically find the source of the vendor locations anyway, so we can just as well not copy their neons now and just include them dynamically. The tricky part is for Drupal sites the contrib module can really be anywhere, any depth into the directory structure (eg. sites/example.com/contrib/modules_starting_with_letter_u/upgrade_status :D) also the vendor folder may be at different places on a site. I see the assumptions drupal-check made seem to hold up (either trying to run it from a drupal docroot or a regular docroot/modules/contrib/dirname), but I am trying to be a bit more flexible here. Let's see if that works.

The tests are not very friendly to modifying the composer stuff, because they try to test upgrade_status as a contrib module but in this case it does not appear like so. I elected to commit this temporarily to get it tested in the branch test where that should not be a problem. Will roll back if it does not work out.

It failed but differently :D See https://dispatcher.drupalci.org/job/drupal_contrib/110178/ unfortunately not enough data that I can dig up to provide a lead... It is just "1 warning" for each run, which may be hiding whatever error. I should figure out how to run patched composer projects locally to be able to test this. Need to level up my composer knowledge to be able to debug this.

Committed this again to see results with my own eyes :D Manual UI testing proves that the update works pretty well, reports a lot more errors for upgrade_status and the only false positive reported is "Class Behat​\​Mink​\​WebAssert not found and could not be autoloaded.".

So its really the tests that need fixing for the better detection. Other than the behat problem.

Uh, hum, I set up a whole new environment to develop the fixes but that produces very different results. Hm. This sounds more in line with what the tests are finding and also expected based on phpstan 12 not depending anymore on Nette/Neon at all, so that expected inherited dependency is not there...

Error: Class 'Nette\Neon\Neon' not found in Drupal\upgrade_status\DeprecationAnalyser->createModifiedNeonFile()

Ok with that eliminated, we are down to the wrapped packaging of phpstan:

TypeError: Argument 1 passed to PHPStan\Command\CommandHelper::begin() must be an instance of _HumbugBoxa750b42bd25b\Symfony\Component\Console\Input\InputInterface, instance of Symfony\Component\Console\Input\StringInput given

I don't think we should be continuing to work around this and instead should just go do #3085327: If curl cannot connect, use exec directly and don't use the curl sandboxing.

Took a last chance to review how drupal-check worked around this, as it does not seem to have any special treatment for the interfaces used, etc. with CheckCommand at https://github.com/mglaman/drupal-check/blob/master/src/Command/CheckCom...... than realized that is it not yet updated to phpstan 12. Well.... https://github.com/mglaman/drupal-check/blob/master/composer.json

Ok this will clearly be a bigger change than expected, so backed it out of 1.x and put into a new 2.x instead.

Stopped tagging this issue with it, but resolved in https://git.drupalcode.org/project/upgrade_status/commit/614a627ea7aa268... with exec()ing phpstan from the found vendor folder. I also rolled all the dynamic neon generation into the analyser instead of trying to include a PHP from the neon, since what I need to include is also based on dynamic info about where the vendor folder is. I think we can consider this fixed for the sake of this issue.

I left the exec() in an HTTP request still since that could still time out/run out of memory. Getting it out of the HTTP request would be still left for #3085327: If curl cannot connect, use exec directly and don't use the curl sandboxing.

For future visitors: I kept getting the dreaded error from #5, Service of type PHPStan\Drupal\ServiceMap: Parameter $drupalServices.

My fix was running this:
rm -rf /tmp/phpstan