Are Drupal's developer dependencies required?

For projects that have tests, phpstan will report a bunch of false positives where the base classes of the test infrastructure are missing. That is I believe the main thing. For projects that do not have tests, the difference will not be apparent though :)

I see, thanks for a fast answer and clarifying this @Gábor Hojtsy!

Since projects with tests are probably in the minority, perhaps it should be stated separately? (See also #3421454-13: Module incompatibility with nikic/php-parser v5.0.0 → )

Updating to Drupal 10 is already hard enough in itself, and many users are struggling, so every redundant step is a potential stumbling block, and should be removed, in my opinion.

Maybe this rewording could be considered?

Installation on sites already using composer

Install Upgrade Status on your existing Drupal site.

Due to third party PHP library dependencies, the module needs to be installed with Composer → .

It is recommended to uninstall Drush with composer remove drush/drush before downloading Upgrade Status, to avoid compatibility issues. You can add Drush again afterwards. Install with Composer, as you would any other module:

$ composer require drupal/upgrade_status

Install Upgrade Status for projects with tests

For projects that have tests, PHPStan will report a bunch of false positives where the base classes of the test infrastructure are missing. So you need Drupal's developer dependencies → , which Upgrade Status does not directly depend on, because they vary based on your Drupal core version. Also, it may be necessary to uninstall Drush first.

$ composer show drupal/core | grep versions
$ composer require --dev drupal/core-dev:[copy version above] --update-with-all-dependencies
$ composer require drupal/upgrade_status

I'm not sure its easier "If this obscure PHPUnit error shows up in your report, install the dev dependencies" in the docs.

I guess one thing we can do is to catch this kind of error and add a tip to install the dev dependencies there within the error.

We would need some kind of reliable list of errors that show up for these cases.

Showing a PHPStan/PHPunit error message to the relevant users directly where the error happens would be a big improvement, since the installation help text can be reduced to just this, which is much less daunting for novices:

Installation on sites already using composer

Install Upgrade Status on your existing Drupal site.

Due to third party PHP library dependencies, the module needs to be installed with Composer → .

It is recommended to uninstall Drush with composer remove drush/drush before downloading Upgrade Status, to avoid compatibility issues. You can add Drush again afterwards. Install with Composer, as you would any other module:

$ composer require drupal/upgrade_status

Finally, install the module using the Extend page or with Drush as you would any other module.

Installation on sites not using composer

[...]

I created ✨ Show PHPUnit, PHPStan error messages to users Active .

Until ✨ Show PHPUnit, PHPStan error messages to users Active lands, what do you think about my suggestion, to first have a simple install instruction, and a separate "install dev for sites with tests" below, as I suggested in #3 on https://www.drupal.org/project/upgrade_status/ → ? You answered, but I am not sure I fully understand it:

I'm not sure its easier "If this obscure PHPUnit error shows up in your report, install the dev dependencies" in the docs.

Currently, everybody is recommended to install dev-tools, which is redundant for most users ...

Of course, if ✨ Show PHPUnit, PHPStan error messages to users Active is easy, and done fast, we can just wait for that, before the project text is updated.

Simplify suggested "Install Upgrade Status for projects with tests" text in Issue Summary.

Update "Problem/Motivation", since questions have been answered.

Projects with tests may be contrib projects. Let's say you have webform and paragraphs. Those have tests. They appear to be compatible but you scan them and they report a bunch of problems. Now they appear not compatible even though you "scanned them wrong". So "sites with tests" I think would be all Drupal sites since some of their contribs will have tests. Now if they ONLY want to scan custom code and/or contribs without tests, then the dev dependencies would not be needed. So I think its a grey line really. Hope this makes sense.

Thanks for your patience @Gábor Hojtsy. At some point, I erroneously conflated the word "project" with "site", but they are not the same ... And you're so right, since most contrib modules or themes ("projects") have tests, this means that "sites with tests" is the vast majority. Sorry for the noise!