Remove deprecated vendor cleanup scripts

Do these count as an api and thus need to wait for 9.x to be removed? asking for a friend: #3082866: composer complains "Skipped installation of bin bin/composer for package composer/composer: file not found in package"

So I think we're a little behind the times here. If we had caught this a bit earlier we could have formally deprecated Drupal\Core\Composer\Composer::vendorTestCodeCleanup() and other methods that aren't needed before Drupal 9.

But it might be that we can't deprecate for 9, and would have to go for 10.

Nevertheless, here's a patch which deprecates for removal before 9.0.x, in hopes that maybe core maintainers don't want to maintain this code any longer than they have to.

Also explicitly marking protected methods as @internal.

There are two methods worth singling out:

removeTimeout() was added in #2911319: Provide a single command to install & run Drupal, I think by mistake. It seems like the idea was to allow you to type composer install-a-quick-start, but then that idea was dropped in favor of a CLI implementation. Marking as deprecated.

upgradePHPUnit() is left over from the good old days of PHP 5 compatibility. It might be in use now as a convenient way to upgrade to a version of PHPUnit ahead of current Drupal. Also has a friend: upgradePHPUnitCheck(). Not marking as deprecated, but as @internal.

Please push back on any of these decisions as needed. :-)

re-roll for 9.1.x deprecation, guess it needs deprecation test and CR

Should we add @trigger_error deprecations inside each of the deprecated methods, or output a warning if the relevant Composer commands are used?

I agree upgradePHPUnit() should stay and just be marked internal, it is about to be revived in #3127141: Use PHPUnit 9 for PHP 7.4+, while keeping support for PHPUnit 8.4 in PHP 7.3

Let's add some kind of messaging to the user. #3162228: Composer 2 Fatal error Call to undefined method Composer\DependencyResolver\Operation\UpdateOperation::getJobType() in /home/mysite/public_html/core/lib/Drupal/Core/Composer/Composer.php:170 shows that these scripts are still in use in the wild and so we need to tell people to stop using them and switch to alternatives before we actually can remove them.

Here a Reroll patch.

Patch #13 is applied successfully and patch #6 giving me error

Patch #13 is applied successfully and patch #6 giving me error

It's expected that patch #6 would not apply to Drupal 9.3. created for Drupal 8.9 and was rerolled in #13 so it would apply to 9.3.

In other words, the patch in #13 only exists because we're all already aware that patch #6 does not apply. There's no need to provide further evidence of that.

#12 still applies. We need some kind of messaging to existing users that these will be removed, and a change record that we can point users to for documentation of the removal and what they should do instead.

reroll for 9.4

Added CR, looks phpunit upgrade also could be deprecated, but not sure about removal from "scripts" section, probably it needs follow-up

Fix CS

@andypost any thoughts about #12/#16 - marking these as deprecated is a start but I think we should show a message somewhere to anyone who is still using these?

++ to #21

This patch adds unsilenced deprecation notices to the three script methods and corresponding tests.

It also includes the fix from #3162228: Composer 2 Fatal error Call to undefined method Composer\DependencyResolver\Operation\UpdateOperation::getJobType() in /home/mysite/public_html/core/lib/Drupal/Core/Composer/Composer.php:170 as ::vendorTestCodeCleanup doesn't work with Composer 2 and it's not possible to execute it from a test case without the fix. As that's the case I do wonder how anyone is actually using these any more.

The root composer.json also includes

        "pre-autoload-dump": "Drupal\\Core\\Composer\\Composer::preAutoloadDump",

which we are deprecating here - I guess this needs removing?!

Fixing custom commands failure.

Adding @group.

I'm still not sure preAutoloadDump should be deprecated or removed here. It is used by both the root composer.json and core/composer.json to ensure that bootstrap classes are added to the autoloader classmap, even for users that don't dump an optimized autoloader.

I find it weird that some plugin takes over composer functionality.

User's build system should be configured to use -o or whatever required, or at least there should be ability to disable(skip) this plugin.

Other option is to populate autoload - classmap at d-org packaging system (at release build for example).

Anyway it requires change record to be filed

At this point I think we should split deprecation(9.4.0) and removal(10.0.x) into separate issues

@andypost this script adds ~15 classes to the classmap that are useful for bootstrap, that is minor compared to the 4800+ that are added if I dump an optimized autoloader.

Having said that we do need an issue to update the vendor classmap as symfony/http-kernel is duplicated and laminas/laminas-zendframework-bridge is no longer a dependency - we should check which classes are needed for bootstrap in Symfony 6 and only list those.

I'm not sure what the deprecation rules are here, but Drupal\Core\Composer\Composer is not marked @internal, and vendorTestCodeCleanup() is not marked @internal or @deprecated.

I'm visiting from #3272110: Drupal 9 and 10's Drupal\Component composer.json files are totally out of date where I noticed that vendorTestCodeCleanup() is still present despite the existence of the vendor hardening plugin.

I guess the next step is to find out if we can deprecate stuff in 9.5.x for removal in 10.x.

Added #3280589: Deprecate Composer Vendor Cleanup Scripts

Postponing this issue on that one, per #30.

Hiding outdated patches.

Nice work! One more simplification we can do then I think this is RTBC.

Thank you @Spokje.

Committed/pushed to 10.1.x and cherry-picked to 10.0.x, thanks!