Problem/Motivation
Sometime we replace an implementation of a class in vendor with one in core, either because we've had to fork it from a dependency we're still planning to use, or because we've moved away from that dependency altogether.
In these cases, we want to inform people to use the new class in core, but because we don't control the code in the vendor class, we can't easily trigger a deprecation notice. Also the class in vendor hasn't been deprecated by the dependency, it's just Drupal core that wants to deprecate its use.
Currently the only way we have to inform people of this is:
1. Change records
2. Static analysis via Drupal check/rector
But it would be useful to be able to trigger deprecation notices during tests too.
Proposed resolution
A brute force way to do this is to class_alias() a class in the core namespace to take over the vendor one, and then add @trigger_error('...', E_USER_DEPRECATED) in there. However this has the potential to add quite a lot of cruft and duplicated logic, just to add a @trigger_error().
Another way might be to add deprecation capability to the autoloader during tests, so that the autoloader itself triggers deprecation notices based on a list of classes.
We could also decide to rely on static analysis for this after all, but in that case should document it in the deprecation policy: https://www.drupal.org/core/deprecation
Comments
Comment #2
alexpottI think this would be really smart. In fact I think it'd be awesome to add it as a composer plugin that used information from composer.json rather than building it into our own special autoloader. The plugin could look in the the extra info for deprecated dependencies and then if there are some prepend an autoloader that triggers a silenced deprecation if a class from that package is requested.
It could also work out if another package has the same dependency which is not deprecated and then not trigger the deprecations.