Class not found error from drupal.org deprecation checker

[jhodgdon-drp]

How is drupal-check installed?

• drupal-check is installed using the phar
• drupal-check is installed globally via Composer
• drupal-check is installed globally using consolidation/cgr
• drupal-check is installed as a dependency to my project

I am not sure how it is installed -- this report is based on output at
https://dev.acquia.com/drupal9/deprecation_status/errors?project=porterstemmer%201.0
from the drupal.org deprecation checker.

Environment:

• OS: Windows/macOS/Linux
• PHP Version: 7.2
• Drupal core: 8.x.x

Again, not sure what the environment is.

Describe the bug

The test results from the drupal.org deprecation checker on https://www.drupal.org/project/porterstemmer are showing a "class not found" error that doesn't make sense. It's saying it cannot find the class Drupal​\​Tests​\​porterstemmer​\​Functional​\​LangCodeTest

However, DrupalCi is able to find this class for automated tests, and it is in:
https://git.drupalcode.org/project/porterstemmer/blob/8.x-1.x/tests/src/Functional/LangCodeTest.php
in the branch that is being tested.

This seems similar to #55 but that issue is marked closed/fixed, so I am opening another issue.

Console output
I don't have the console output. All I have is what is on the web page output:

Class Drupal​\​Tests​\​porterstemmer​\​Functional​\​LangCodeTest was not found while trying to analyse it - autoloading is probably not configured properly.

[mradcliffe]

This didn't seem related to #124. I tried testing this manually with drupal-check so it's possible that at some point this was broken, but now is fixed in the project.

Doing a little research mglaman/phpstan-drupal:0.11.14 was refactored, but that doesn't explain that on 2019.01.18 which used 0.12.1 that the same issue occurred.

This is probably unrelated to drupal-check because drupalci uses phpstan directly so the Acquia reports are generated from that and not a local drupal-check run.

[mradcliffe]

Trying to run the same thing drupalci does manually confirms that it's still an issue. I think this is because there's different phpstan configurations and phpstan doesn't actually use the autoloader in phpstan-drupal.

~/dev/phpstan-drupal/vendor/bin/phpstan analyse --no-progress --error-format checkstyle -c ~/dev/phpstan-drupal/phpstan.neon ~/sprint/sprint-20191111-0838/drupal8/modules/porterstemmer.

I found extension.neon and if I include that within phpstan-drupal's phpstan.neon file then I get a different output for the above command.

Maybe phpstan-drupal and/or drupalci should use a different phpstan.neo file?

[mradcliffe]

https://git.drupalcode.org/project/infrastructure/blob/master/stats/project_analysis/d9readiness.sh#L21

I copied that to a new blah.neon file, changed the drupal root to the full path to my drupal root above, and then I ran the command above with "blah.neon" instead of "phpstan.neon", and that came up clean.

I also tried 0.12.1 and it ran clean as well. So I'm still confused as to why the output isn't correct on drupalci.

[mradcliffe]

Didn't plan on going down the rabbit hole, but I documented everything and tried reproducing using phpstan-drupal as part of the drupal root and still couldn't reproduce.

I created https://www.drupal.org/project/infrastructure/issues/3107858 because this seems like something going on with CI rather than anything in phpstan-drupal itself.

[mradcliffe]

So, I didn't realize the 1.0 tag was 3 years old and uses the old functional test class location. I think if there was another release, then it should be working as expected, @jhodgdon-drp